The 24Observe MCP server connects any Model-Context-Protocol assistant — Claude, an IDE assistant, your own agent — to your organisation through a curated, fail-closed set of tools, authenticated by a token you scope. So you can ask an assistant to investigate an incident, search your logs, or check what is on fire, and it does the work by calling vetted tools — never with more access than you granted, and always on the record.
An AI assistant that can only talk is a chatbot; an assistant that can also see your incidents, search your logs, and adjust a monitor is an operator. The Model Context Protocol is how you give an assistant that ability — and the whole question is how to do it without handing over the keys to everything.
24Observe answers that with a curated MCP server. Rather than exposing the entire API surface to an assistant — which would include sensitive administrative actions an assistant has no business calling — the MCP server presents a deliberately chosen allowlist of tools that are safe and useful for an assistant to invoke: search and tail logs, read metrics, list and inspect incidents and the analyst's verdicts, walk the context graph, and, where you permit it, manage monitors and acknowledge incidents. It is fail-closed by design: anything not explicitly on the allowlist is not exposed at all, so the boundary is defined by what is permitted, not by remembering to forbid each dangerous thing.
On top of the allowlist sits the token. The MCP server's entire authority comes from a scoped token you mint and place in its environment, so even within the allowlist the assistant can only do what the token's scopes permit. A read-only token lets it investigate and answer questions while being structurally incapable of changing anything; a token with specific write scopes lets it take exactly the actions you intend and no others. And everything it does is recorded in the audit trail, attributed to that token, so an assistant's actions are never confused with a human's and are always reviewable after the fact.
Those three layers — curated allowlist, scoped token, full audit — are what make it genuinely safe to let an AI operate your observability platform. The rest of this guide is how to set it up, starting read-only, and how to widen access deliberately as you build trust.
The shape is the same for any MCP-speaking client: mint a scoped token, point the client at the 24Observe MCP server, and start asking.
Under Settings → API tokens, create a token for this assistant. Start read-only: grant read scopes for the areas you want the assistant to see — logs, incidents, metrics, context — and nothing more. Name it for the assistant it belongs to, so the audit trail and any future revocation are unambiguous. Copy the token; you will place it in the client's configuration.
Tell your MCP client to launch the 24Observe MCP server and pass it the token. In a typical client configuration that looks like this:
{
"mcpServers": {
"24observe": {
"command": "npx",
"args": ["-y", "@observe24/mcp"],
"env": {
"OBSERVE24_TOKEN": "obs_<your_scoped_token>"
}
}
}
}
The exact location of this configuration depends on your client — a desktop assistant, an IDE extension, or your
own agent runtime — but the contents are the same everywhere: launch @observe24/mcp, and give it
your scoped token in the environment. On start, the client discovers the curated tools the server exposes and
makes them available to the assistant.
With the client connected, simply ask a question that requires platform data. The assistant will call the appropriate curated tools, reason over the results, and answer:
You: "What incidents opened in the last hour, and what did the analyst conclude?"
Assistant: (calls list_incidents, then get_incident for each)
→ 2 incidents. #5210 — checkout latency, root cause: upstream payment timeout
(analyst verdict, 6 citations). #5211 — disk filling on db-primary, runaway log. That is the whole loop. The assistant decided which tools to call, called them within the bounds of your read-only token, and synthesised an answer — and every one of those calls is sitting in your audit trail, attributed to the token, for you to review.
You are not trusting the assistant to behave; you are bounding what it can do. Each layer is independent, so a gap in one is caught by the others.
The right way to adopt an MCP-connected assistant mirrors how you would onboard a capable new hire: start with read access, watch how they work, and extend responsibility as trust is earned. For the first while, keep the token read-only. An assistant that can search your logs, read your incidents and the analyst's verdicts, walk the context graph, and summarise what is happening is already enormously useful — it can answer "what changed," triage your morning incident list, and pull together the context for an investigation — and it can do none of it dangerously, because it physically cannot change anything.
Spend that period reading the audit trail. Because every tool call the assistant makes is recorded and attributed to its token, you can see exactly what it did and judge whether its behaviour is what you want. This is the evidence on which you widen access, and it is far more reassuring than any promise: you are not trusting the assistant's intentions, you are observing its actions.
When you are ready to let it act, mint a new token with specific write scopes for the actions you want — perhaps acknowledging incidents, creating monitors, or adjusting detections — and update the client to use it. Because the posture is deny-by-default, this is always a deliberate widening, never an accident: the assistant gains exactly the new capability you granted and nothing adjacent to it. If you ever want to pull it back, revoke the token and you are instantly back to no access, with the audit trail intact.
Handled this way, an MCP-connected assistant becomes a genuine member of your operations — investigating, summarising, and eventually acting — without ever being a security liability. The boundary did the work, so you did not have to rely on trust alone. For building a fully custom agent against the complete API rather than the curated MCP surface, see the agent cookbook and the API for agents.
It helps to be clear about the two ways an automation can reach the platform, because they suit different situations. The MCP server is the curated, fail-closed surface designed for an assistant — something reasoning in the moment, deciding which tools to call, where you want strong guardrails because the caller is improvising. The raw API is the complete surface, designed for trusted backend automation — a deploy pipeline, a chatops bot, a scheduled job — where the caller is a program you wrote and reviewed, doing a known set of operations. Both authenticate with scoped tokens and both are fully audited; the difference is whether you want the safety of a curated allowlist or the completeness of the full surface.
A useful rule of thumb: if a human is in the loop talking to an assistant, prefer MCP, because the allowlist protects you from the open-ended nature of natural-language requests. If a machine is executing a fixed workflow you control, the raw API is appropriate, scoped tightly to that workflow's needs. Many teams use both — an MCP connection for their analysts to investigate conversationally, and a few narrowly-scoped API tokens for their pipelines and bots — and the audit trail keeps the two cleanly distinguished.
As more people connect assistants, a little discipline keeps it manageable. Mint one token per assistant or per person rather than sharing a single token, so the audit trail tells you who did what and you can revoke one without disrupting the others. Keep the default posture read-only, and treat any write scope as a deliberate grant tied to a specific need. Periodically review the tokens in use and revoke any you cannot account for — an orphaned token with broad scope is exactly the kind of quiet exposure worth catching early. None of this is heavy process; it is the same least-privilege hygiene that applies to every credential, applied to the assistants that are increasingly part of how your team works.
Treat the assistants you connect as a real, growing part of your operations surface — because that is what they are becoming. The same review cadence you apply to human access applies here: periodically confirm each connected assistant still has a reason to exist and still has the narrowest scope that lets it do its job. An MCP connection is not a set-and-forget integration; it is a standing grant of access that deserves the same ongoing care as any other, and the audit trail is what makes that care cheap — a short read rather than an investigation.
Mint a scoped token, point your MCP client at the 24Observe server, and let an assistant investigate and operate inside a boundary of allowlist, scope, and audit.