Agency Workflows with MCP and n8n: Client Status Without a Dashboard Login

An AI assistant can pull the status of your client sites itself, without anyone on your team opening the dashboard. What makes that possible is an MCP server: a standard interface an assistant uses to read monitors, incidents and uptime figures. Your client asks in Slack whether their site is up, and twenty seconds later they have the uptime of the last 30 days and the most recent incident. Not because someone clicked faster. Because the assistant fetched the data itself.

The workflow before this existed: why status questions are expensive

Status questions do not cost you minutes. They cost you context switches. The question lands in the client's Slack channel and gets answered in a different tool: open the dashboard, log in, find the client, open the monitor, change the range, read the number, switch back, write the reply. Eight steps for one sentence.

Now run that against your portfolio. With 40 sites under management and two or three status questions a week, you are looking at several hours a month, sliced into two-minute pieces spread across the day. Each one is too small to log, and none of them ever reaches an invoice.

The real damage sits elsewhere. The answer arrives late, it arrives thin, and it arrives without proof. "All good" is reassurance, not service delivery. You just spent the one moment where a client asks, unprompted, what your retainer is actually worth.

What changes when the assistant is allowed to read your monitors

The Model Context Protocol is an open standard that lets an AI assistant call another application's tools directly instead of operating its interface. The assistant receives a list of available tools, picks the right one, calls it and works with the result.

Uptimeify runs a stateless MCP server for exactly that at POST https://uptimeify.io/mcp over Streamable HTTP. 20 check tools work with no account and no token, among them check_ssl, check_dns, whois and website_status. Thirteen more read your own data once a token is present:

The difference day to day is not the volume of data. It is the location. The question gets answered where it was asked. Nobody switches tools, nobody logs in, and the reply carries a number instead of a reassurance.

Three concrete agency workflows

Status checks in chat instead of a dashboard login

Your client asks whether their site is up. Your team passes the question to the assistant, word for word: "What was the uptime for this client domain over the last 30 days, and when was the last incident?"

The assistant assembles the answer in three steps: list_monitors to find the monitor, uptime_summary for the period, list_incidents for the most recent incident. Back comes one sentence with a percentage, a date and a duration. The account manager reads it, sanity-checks it and drops it into the client channel. Twenty seconds instead of eight steps.

One detail that decides the quality of the answer: the numbers come from your account, not from the language model. The assistant phrases, it does not estimate.

Report prep: the uptime summary as a text block

The monthly report is mandatory, but the commentary in front of it is manual work. That part can be prepared: uptime_summary for the month, list_incidents for the same window, and out of it two or three sentences in language your client actually reads.

The finished report still comes white-labeled out of the platform. The assistant supplies the interpretation, not the data and not the PDF. How to build the report itself is covered in the guide on creating an SLA report for clients.

Incident context in the ticket, at the moment it is opened

A support ticket for a client site comes in. Before anyone picks it up, the assistant pulls the recent incidents for that exact monitor through list_incidents and check_history and attaches them to the ticket.

Whoever takes it sees at a glance whether this is a one-off or the fourth outage in two weeks. That changes the priority, the reply to the client, and the question of whether a hosting conversation is overdue.

n8n and MCP: the server as a node in your existing automations

If your automation already lives in n8n, you do not need a second home for this. n8n covers both directions: the MCP Client Tool node attaches to an AI Agent as a tool and calls an external MCP server. The MCP Server Trigger node goes the other way and exposes your own workflows as tools.

For Uptimeify the first direction is the relevant one. A typical setup from agency practice:

1. Trigger: a message in the client channel contains a keyword such as "status" or "down".
2. AI Agent: an agent node with a clear system instruction on which client belongs to which channel.
3. MCP Client Tool: connection to the Uptimeify MCP server, authenticated with a bearer token.
4. Reply: the agent phrases the answer and posts it back into the thread, or parks it as a draft when a human should read it first.

Two details that save you time during the build. First: the access token expires after 3600 seconds, so an automation that runs permanently has to re-mint it on a schedule rather than store it once. Second: check which transport the MCP Client Tool node offers in your n8n version. The node started on SSE, Streamable HTTP came later, and the Uptimeify endpoint speaks Streamable HTTP.

The rate limits are generous for this kind of use: 120 requests per minute per IP on the endpoint, 60 per minute per authenticated tool. An agency with a few dozen clients stays well below that. Anyone above it gets a 429 and now knows the loop was built wrong.

What the assistant is not allowed to do, and why that sells

Agent tokens at Uptimeify are read-only. Every write attempt ends in 403 with data.code = agentTokenReadOnly. That holds regardless of what the prompt says: an agent cannot create a monitor, pause one, set a maintenance window or acknowledge an incident.

Access is fenced twice over. The api.read scope reaches GET /api/websites*, GET /api/incidents* and GET /api/health, bound to the organization of the user who granted access, or to a single customer inside it. And that grant is issued by a signed-in human through a confirmation, never by the agent on its own behalf.

This is the part you need in the client conversation. When an end client asks whether "an AI is now sitting on our systems", the answer is not a reassurance but a list: read access, three endpoints, token expired after an hour, granted by a human, revocable at any time. Plus the infrastructure it runs on: European stack, Frankfurt, no US sub-processors. You put those points into your security section the same way you already do for CMS access.

Limits: what still does not work today

Writing stays out. Onboarding, configuration changes and anything that alters state still run through the dashboard or a regular API token issued by a human. What that looks like over the API is covered in the piece on onboarding client sites via API.

The hour is the unit. The access token expires after 3600 seconds. Invisible inside a chat, a building block you have to plan for in a permanently running automation.

The assistant reads, it does not judge. 99.2 percent uptime can be a planned maintenance window or a hosting problem. That interpretation comes from you, and it is exactly what your client pays the retainer for.

MCP does not replace alerting. An assistant answers when it is asked. An outage at three in the morning asks nobody. Alerting keeps running through escalation policies and channels; MCP sits next to it and answers questions during the day.

The difference between an agency that runs monitoring and one that sells it was never the tooling. It was always how fast, and how provably, the client gets an answer. MCP shortens that path to one sentence in a chat. What you make of it is still your work.