MCP server: planned

Where things stand

Tenium does not currently provide a Model Context Protocol server. There is nothing to install, no endpoint to connect an assistant to, and no beta list with a launch date. We are writing this page because people ask, and because a vague "AI integration coming soon" is worse than a plain account of what exists and what is only an idea.

What does exist is the REST API. Everything described below could be done with it today, by a script or by an assistant that can run HTTP requests.

What an MCP server would let an assistant do

The first version we would build is deliberately small and mostly read-only. The idea is to let someone ask their assistant a question in their own words and get an answer from live data, without opening a dashboard.

• Read monitor status. "Which of Client A's monitors are down right now?" or "What was the response time of the shop's checkout page this week?" These map to listing monitors and reading check history.
• Read incidents. "Summarise last night's incident: when it started, which regions confirmed it, how long it lasted." That maps to reading an incident with its evidence.
• Make a small, reversible change. "Create a maintenance window for Saturday 02:00 to 03:00 on the staging monitors." Writing is the part we would be most careful with, which is why it would sit behind a write-scoped key and explicit confirmation by the person using the assistant.
• Add context. "Add a note to the incident saying the host restarted PHP-FPM." Notes already exist in the API and appear in the timeline and in monthly reports.

One caveat that matters: maintenance windows cannot be created through the REST API today. They are set in the app. An MCP tool for them would first need that endpoint, so it is a dependency, not a promise.

Design principles we would hold ourselves to

• No new permissions. The server would use the same API keys and the same scopes as everything else. A read key could never change anything, and revoking a key would end an assistant's access immediately.
• Client isolation preserved. A key scoped to one client workspace would only ever expose that workspace's monitors.
• Small tool surface. A handful of well-named tools, not a mirror of every endpoint. Assistants pick tools better when there are fewer of them.
• Logged. Changes made through it would appear in the same audit trail as changes made in the app.

What you can do today

If you want an assistant to help with your monitoring right now, the practical route is the REST API. Create a read-only key under Settings, then API keys, give your assistant the ability to run curl or a small script, and let it call GET /monitors, GET /incidents and GET /monitors/{id}/checks. Keep the key read-only unless you have a specific reason. Write keys are available on Pro and Agency, and every example is in the API documentation and the developer page.

For alert-driven automation there is a second route: signed webhooks. A webhook contact delivers incident events to a URL you control, where a small service can hand them to whatever tooling you run. See webhook payloads.

Tell us what you would use it for

If an MCP server would help you, contact us and say which assistant you use and what job you would hand over. Concrete requests shape what we build first, and we would rather build the three tools people actually use than twenty they do not. This page is not indexed by search engines on purpose, since it describes something that does not exist yet.