Next-Gen Observability for Modern Systems | Atatus
Atatus
Atatus is the next-gen AI observability platform for engineering teams, covering APM, Logs, RUM, Infra monitoring, and SIEM in one centralized platform. Try free trial!
This listing identifies a third-party MCP server. MCPBundles is not affiliated with, sponsored by, or endorsed by the service or its operator unless stated on this page.
This server may ask you to sign in when your AI client connects.
Last probed Nov 3, 2026 · mcp.atatus.com
67tools discovered
For AI agents — MCPBundles Directory API
For MCP client apps (human connect):
MCP connect URL: https://mcp.atatus.com/mcp
Skill page: https://www.mcpbundles.com/skills/atatus-mcp-cda5dc0119
Explore capabilities (67)
read 24
write 1
Showing 25 of 67
Showing 25 of 67 tools from the public preview. Connect the server to inspect the full live tool list.
Get17
List5
Other capabilities3
List Projects
read
list_projects
List every project (application) in the Atatus account — returns name, product type, Lang/Framework (subType), and a stable project ID for each. Reads the projects collection, which holds the APPLICATION-type products: APM and RUM/Browser (web) apps (plus mobile-RUM apps if any exist). Use this FIRST to resolve a service name to its project ID.
APM activity (APM projects only): also reports whether each APM project is actually SENDING DATA in the time_dur window — active, live (last event < 10
List Projects — List every project (application) in the Atatus account — returns name, product type, Lang/Framework (subType), and a stable project ID for each. Reads the projects collection, which holds the APPLICATION-type products: APM and RUM/Browser (web) apps (plus mobile-RUM apps if any exist). Use this FIRST to resolve a service name to its project ID.
APM activity (APM projects only): also reports whether each APM project is actually SENDING DATA in the time_dur window — active, live (last event < 10
Get Apm Metrics — Project-level Apdex summary for ONE APM project (WEB transactions only): apdex score, successful (error-free) WEB request count, and the satisfied/tolerated/frustrated bucket counts (and their percentages). Targets APM projects (not Browser/RUM); the transaction filter is APM-only. Use this for "what is the Apdex of project X?" or "is the service overall healthy?".
IMPORTANT: this endpoint returns ONLY Apdex data, NOT response time, throughput, or failure rate, AND is scoped to WEB transactions
Get Recent Errors — List recent error groups (deduplicated exceptions) for an APM or browser project. Use this for "what errors are happening right now?", "any new error type today?", "errors since the deploy?". Returns one row per error fingerprint, not per occurrence.
When to use: triage / "what is broken" questions; narrowing by release stage (env), request URL, or message keyword.
When NOT to use: full stack trace for a single error → get_error_details; individual occurrences of one error → get_error_events.
Get Error Details — Get the full story for ONE error group: summary (first/last seen, total events, affected users) plus a few recent events with stack trace + request context + deployment metadata. Use this AFTER get_recent_errors when the user wants "show me the stack trace", "why is X failing?", or "what request triggered this error?".
IMPORTANT — time window: both the summary counts (Total Events / Affected Users = the blast radius) AND the sample events are scoped to time_dur, which DEFAULTS TO 1d. If you fou
Get Error Events — List individual occurrences (events) of one error group, each with full stack trace, request context (method/path/status), user info, and agent / release stage. Use this when get_error_details (which returns ~3 events) is not enough — for example, "did this fail for one user or many?", "is it happening on all hosts or one?", "show me 10 recent occurrences".
When to use: after get_recent_errors / get_error_details, when you need more than a handful of raw event samples for the same Error ID.
Whe
Get your MCP into directories
A working endpoint is step one. Directory coverage is the coordinated launch across ChatGPT, Claude, Cursor, the MCP Registry, and community indexes.
What is the Next-Gen Observability for Modern Systems | Atatus MCP server?
Atatus is the next-gen AI observability platform for engineering teams, covering APM, Logs, RUM, Infra monitoring, and SIEM in one centralized platform. Try free trial!
How do I connect Next-Gen Observability for Modern Systems | Atatus to my AI agent?
Use the MCP endpoint listed on this page in your MCP client configuration. One-click install pills support Claude, Cursor, VS Code, and other hosts. Copy the remote MCP URL if your client needs a manual entry.
Operate this server?
Request removal if you do not want Next-Gen Observability for Modern Systems | Atatus listed here, or claim the listing if you want to manage it on MCPBundles.
Operate Next-Gen Observability for Modern Systems | Atatus?
This server appears in the MCPBundles directory. Verify you operate it to take over the listing — name, description, logo, contact email, and skill content. We email a 6-digit code to a maintainer address your server publishes in /.well-known/security.txt or /.well-known/mcpbundles.json. Free, takes about a minute.
MCPBundles publishes this directory for MCP discovery. Except where we host or operate an offering, third-party services run under their own terms. Product and company names on this page are used in a descriptive, identifying way (including under nominative fair use where applicable); they remain the property of their owners. Nothing here grants you rights in those marks, and nothing here is an offer to sell a third party's services. Terms · Request removal
More in monitoring
Other MCP servers in this category from the directory index
Get Recent Transactions — List transaction groups (endpoints / background jobs) for an APM project with per-endpoint avg/min/max response time, successful-request count, apdex, total/ok/failed request counts and failure rate. Use this for "which endpoint is slowest?", "what is the failure rate of /checkout?", "is this transaction misbehaving?".
When to use: ranking endpoints by latency or failure, finding the slow/erroring endpoint behind a service-wide regression, narrowing to one transaction by name via `transaction`.
Get Transaction Spans — Breakdown of where time is spent INSIDE one transaction — slowest spans/segments classified as DB / External (downstream API) / Internal-App, with response time, call count, and % of total time consumed. The category is derived from each span's kind (Database=DB, Remote=External downstream call, framework/Custom=Internal app code); the engine/host (Postgres, Redis, the called hostname) is shown as a secondary "Engine" detail. Use this for "WHY is /checkout slow?", "is the DB or the downstream AP
Get Apm Database Calls — APM view of the database calls your instrumented application makes — the APM "Databases" tab, from apm.layers. Returns the database engines your app talks to (PostgreSQL, MySQL, Redis, MongoDB, …) with avg latency, call volume, and share of DB time, plus the SLOWEST database operations/queries (avg/min/max latency and call count). Use for: "how are my DB calls performing?", "which queries are slowest?", "how much of my response time is database time?". Native Atatus APM agents only (Node.js/Java
Get Recent Deployments — List the recent deployment markers for a project — version, who deployed, when, environment, repo, revision. Use this for "did we ship anything before the spike?", "what is currently in prod?", "when did v2.4.0 go out?".
When to use: correlating an error or latency regression with a deploy; finding the version to pass to get_recent_errors.version for the "is this regression in the new build?" workflow.
When NOT to use: the AUTOMATED "what changed around this incident?" analysis → correlate_depl
Get Service Health Summary — One-call "is this service healthy?" — returns a HEALTHY/WATCH/DEGRADED verdict plus golden signals (Apdex, service-wide failed-request count + error rate from HTTP 4xx/5xx, top open error fingerprints, top 5 endpoints by request count with avg latency and per-endpoint failures, most recent deploy) for an APM project in a single response. The error rate is derived from transaction failureCount, so a service with failing requests but no open error fingerprints is still flagged — the "no open error
Diagnose Service — Composite incident triage for ONE APM service — the "what is wrong with X, and why?" tool to run FIRST when a service is misbehaving. In one call it pulls the golden signals (Apdex + HTTP 4xx/5xx failure rate), the top open error fingerprints, the error-count trend (WHEN errors started climbing and when they peaked), and the most recent deploy — then returns a HEALTHY/WATCH/DEGRADED/UNKNOWN verdict plus a RANKED, evidence-cited hypothesis of the likely cause (e.g. "deploy vX landed ~4 min before
Correlate Deploy With Incident — Answer "what changed?" — the #1 SRE question during an incident. Given an incident timestamp (or "now" if omitted), list deployments in the lookback window and report the error delta (before vs after each deploy) for the project. Single call replaces the manual sequence of get_recent_deployments → get_recent_errors (before window) → get_recent_errors (after window) → eyeball deltas.
Honest scope: the errors listing endpoint often does not return per-group event volumes at list time (too expensi
Get Apm Timeseries — Performance OVER TIME for one APM project: response time, throughput, and HTTP-failure count bucketed across the range, plus a window summary (avg response time, throughput, failure rate/count). This is the data behind the APM dashboard line charts. Use this for "how did latency trend over the last 24h?", "did throughput spike?", "when did failures start?". APM projects only.
When to use: trend / over-time questions, spotting WHEN a regression began.
When NOT to use: a single point-in-time apde
Get Error Trends — Error count OVER TIME for one APM or Browser (RUM) project - error occurrences bucketed across the range, so you can see WHEN errors spiked rather than just which errors exist. Use this for "did errors spike after the deploy?", "is the error rate climbing?", "when did this start?". APM and Browser projects only (not infra/logs/synthetics).
When to use: error trend / over-time / "when did it start" questions.
When NOT to use: the list of distinct errors → get_recent_errors (APM) or get_browser_e
Get Api Analytics — Break an APM service's real request traffic down by a chosen dimension — country, endpoint (path), customer (companyId), IP, browser, OS, device, domain, host, or request name — with request count, average duration, and failure count/rate per row. This is the tool for "which COUNTRY is getting the hits?", "which CUSTOMER sends the most traffic?", "which ENDPOINT is the hotspot?", "is one IP hammering us?", "are errors concentrated in one region/browser?". Powered by the API Analytics add-on (pro
Update Error Status — WRITE - change one error group's status: Resolved (mark fixed), Ignored (mute - stops notifications), or Open (reopen). The API-driven equivalent of resolving/ignoring an error in the Atatus UI, so an agent or external system can manage error state without the dashboard. APM projects.
When to use: "mark error X resolved", "ignore this error", "reopen it". Get error_id from get_recent_errors.
NOTE: this MUTATES state. A Resolved error can reopen if it recurs; an Ignored error stays muted and pro
Get Kubernetes Overview — Cluster-wide K8s summary: counts + percentages for Nodes, Pods (running/pending/failed), Containers, Deployments, DaemonSets, StatefulSets, Services, PVs, PVCs, HPAs. Use this as the FIRST K8s tool when the user asks "is the cluster OK?" / "give me a cluster overview".
When to use: opening triage for any K8s incident, dashboard-style summary.
When NOT to use: per-pod / per-node detail → list_kubernetes_pods / list_kubernetes_nodes; just the unhealthy workloads → get_kubernetes_unhealthy_workloa
List Kubernetes Pods — List Kubernetes pods with status, node, CPU, memory, restart count, and owning workload (Deployment / DaemonSet / Job / CronJob / ReplicaSet). Use this for "which pods are crashing?", "any pod in CrashLoopBackOff?", "what is running in namespace X?", "find pods with high restart count".
When to use: pod-level triage across the cluster or a namespace; filtering by cluster/namespace to scope the view.
When NOT to use: ONE specific pod with its events → get_pod_details; pods stuck Pending (schedul
Get Kubernetes Pending Pods — List pods stuck in Pending phase with their (often empty) node assignment and creation time. Use this for "why is pod X not starting?", "any pods stuck Pending?", "is the scheduler healthy?".
When to use: scheduling failures — insufficient resources, taints/tolerations, affinity rules, image pull problems before bind.
When NOT to use: pods that are running but crashing → list_kubernetes_pods filtered by status; the actual scheduling failure reason (FailedScheduling, etc.) → get_kubernetes_event
List Kubernetes Nodes — List Kubernetes nodes with capacity (CPU/memory cores, pod allocatable/capacity), age, AND health conditions (Ready, MemoryPressure, DiskPressure, PIDPressure) merged from /nodes + /nodes/status in one call. Use this for "which node is under pressure?", "is the cluster full?", "why can pods not schedule?", "show node capacity".
When to use: node-level resource and pressure investigation; finding the node behind eviction events.
When NOT to use: which pods are running on a hot node → list_pods_o
List Kubernetes Deployments — List Kubernetes Deployments with desired / available / unavailable / up-to-date pod counts and age. Use this for "is rollout X complete?", "any deployment with missing pods?", "show all deployments in namespace Y".
When to use: post-deploy verification, finding deployments with unavailable pods, namespace inventory.
When NOT to use: WHICH pods of a deployment are failing → list_kubernetes_pods filtered by namespace; cluster-wide unhealthy summary → get_kubernetes_unhealthy_workloads; rollout *r
Get Kubernetes Events — Get Kubernetes events — the stream of warnings, errors, and state changes across pods, nodes, and other resources. CRITICAL for troubleshooting: why pods failed to schedule, why containers crashed, image-pull failures, OOM kills, and more. Use for "why did this pod fail to start?", "what happened in the cluster in the last hour?".
When NOT to use: ONE pod full state → get_pod_details; a cluster health rollup → get_kubernetes_overview / get_kubernetes_unhealthy_workloads; Docker (non-K8s) contain
Get Kubernetes Unhealthy Workloads — One-call cross-workload health check: returns the unhealthy Deployments, DaemonSets, and StatefulSets in a single response. Use this for "what is broken across the cluster?", "any workload with missing replicas?".
When to use: incident triage when you do not know which workload type to look at; daily sanity check.
When NOT to use: list ALL deployments (healthy or not) → list_kubernetes_deployments; pod-level failures inside an unhealthy workload → list_kubernetes_pods then get_pod_details.
Nex
Get Pod Details — Full picture for ONE Kubernetes pod in a single call — state (status, node, cluster, namespace, CPU, memory, restart count, age, owning Deployment/DaemonSet/Job/CronJob) AND recent events for that pod (FailedScheduling, OOMKilled, CrashLoopBackOff, Liveness/Readiness probe failures, ImagePullBackOff, BackOff). Approximate equivalent of "kubectl describe pod" for an on-call SRE with no cluster access.
When to use: you already have the exact pod name and want the full story without three separate
List Pods On Node — List pods running on ONE specific Kubernetes node, sorted by CPU or memory. Use this for "which pods are eating node X?", "what is on this node?", "find the noisy neighbor on the hot node".
When to use: AFTER list_kubernetes_nodes flags a node as hot / under pressure; before draining or cordoning a node.
When NOT to use: pods across the whole cluster → list_kubernetes_pods; node capacity itself → list_kubernetes_nodes.
Next steps: pick the top pod by usage and call get_pod_details pod_name=<po
Showing the first 25 tools — full list and schemas: Directory API.
How many tools does Next-Gen Observability for Modern Systems | Atatus provide?
MCPBundles probed 67 tools on the live server. The tool list on this page reflects what was discovered at the last refresh — connect your client to see the full set available to your session.
What authentication does Next-Gen Observability for Modern Systems | Atatus require?
Next-Gen Observability for Modern Systems | Atatus may require signing in to the provider before tools can run. Connect through MCPBundles or your MCP client and complete any provider login when prompted.
Don't want this listed?
Request removal from the MCPBundles directory. We stop publishing this listing on mcpbundles.com.
MCPBundles is an independent platform built on the open Model Context Protocol standard. MCPBundles is not affiliated with, sponsored by, or endorsed by Anthropic PBC.