Tool Reference

This page lists all 67 tools exposed by the Atatus MCP server, grouped by the Atatus product each one answers questions about. For each tool you will find its description, why it is useful, a sample question that triggers it, its inputs, and typical next steps for chaining.

You never call these tools by hand. Your AI assistant reads this same list from the server and picks and chains the right tools based on your question. The reference is here so you know what the assistant can answer, and so you can name a tool directly when you want a specific one.

All tools are read-only except update_error_status, which is the only tool that writes. Write tools require a Read & Write API key; a Read-scoped key can call everything else. The Access column in each table shows this per tool.

Coverage by product

Tools that summarise instead of listing

Three tools return the shape of what is happening rather than a row per record. Each one lives in the section for the product it reads, because that is where you will look for it:

The grouping and ranking is plain deterministic computation inside the tool — no model and no inference, so the same input always produces the same output.

Picking the right project ID

Most APM, Browser, and Mobile tools need a project_id. Call list_projects first: it returns every application in the account with its product type, and the assistant uses that type to route correctly.

Passing a Browser project ID to an APM-only tool (or the reverse) returns an empty result rather than an error, so the product type matters.

Infrastructure, Kubernetes, Logs, Database Monitoring, and Synthetics are not projects. Their tools take a hostname, cluster, check_id, or no scope at all, and they never appear in list_projects.

Most time-windowed tools accept a time_dur parameter. See Time ranges and Response size and pagination at the bottom of this page.

APM / Application

list_projects

• Description: Returns every application in the account with its name, product type (APM, Browser, Mobile), language or framework, and a stable project ID. For APM projects it also reports whether they are actually sending data in the window, computed from real telemetry rather than a stale activity marker.
• Use Case: The discovery handshake. Every APM, Browser, and Mobile tool needs a project_id, and this resolves a service name to one so you never have to look up an ID.
• Sample Question: "What projects do we have in Atatus?"
• Inputs: time_dur (optional, default 1h; affects only the APM active/inactive verdict, never which projects are listed).
• Next Steps: Pass the returned ID into the tools for that product type. Infrastructure, Kubernetes, Logs, Database Monitoring, and Synthetics are stored separately and will not appear here.

get_apm_metrics

• Description: Project-level Apdex for one APM project: Apdex score, the satisfied / tolerated / frustrated bucket counts and percentages, and the error-free request count.
• Use Case: The quickest read on user-perceived responsiveness for a whole service.
• Sample Question: "What's the Apdex for order-service today?"
• Inputs: project_id (required), time_dur (required), timeStart, timeEnd, transaction (substring filter).
• Next Steps: This tool returns Apdex only. For response time, throughput, and failure rate use get_recent_transactions or get_apm_timeseries. It also covers web transactions only, so background jobs and consumers are excluded.

get_service_health_summary

• Description: A HEALTHY / WATCH / DEGRADED verdict plus the golden signals in one call: Apdex, service-wide failed requests and error rate, top open error fingerprints, the top endpoints by request count with their latency and failures, and the most recent deployment.
• Use Case: Answers "is this service OK right now?" without the assistant making five separate calls.
• Sample Question: "Is checkout-service healthy right now?"
• Inputs: project_id (required), time_dur (default 1h).
• Next Steps: On WATCH or DEGRADED, run diagnose_service for the ranked cause, or get_error_details and get_recent_transactions to drill in yourself.

diagnose_service

• Description: Composite incident triage for one APM service. In a single call it pulls the golden signals, the top open errors, the error trend (when errors started climbing), and recent deployments, then correlates them into a ranked probable cause.
• Use Case: The tool to run first when a service is misbehaving and you want the why, not just the what.
• Sample Question: "What's wrong with payments-api, and why?"
• Inputs: project_id (required), time_dur (default 1h).
• Next Steps: Follow the ranked cause with get_error_details for a stack trace, get_transaction_spans for latency, or correlate_deploy_with_incident to pin the deploy.

get_recent_errors

• Description: Lists error groups (deduplicated exceptions) ranked by impact, with occurrence counts and affected users. Works for both APM and Browser projects.
• Use Case: The front page of any incident: what is breaking, right now, ranked.
• Sample Question: "Show me the top 5 unresolved errors in checkout-service in the last hour."
• Inputs: project_id (required), time_dur (required), timeStart, timeEnd, status (Open, Resolved, Ignored, All; default Open), limit (default 5), page, sortby (events, firstAt, lastAt), env, url, message.
• Next Steps: Take an error_id into get_error_details for the stack trace, or get_error_trends to see when it started.

get_error_details

• Description: The full story for one error group: first and last seen, total events, affected users, plus a few recent events with stack trace, request context, and deployment metadata.
• Use Case: You know the error exists; now you need the stack frame, the triggering request, and the deploy that introduced it.
• Sample Question: "Tell me everything about error abc123."
• Inputs: project_id (required), error_id (required), time_dur (default 1d), timeStart, timeEnd, event_limit (default 3).
• Next Steps: Use get_error_events when three sample events are not enough to see the variation.

get_error_events

• Description: Individual occurrences of one error group, each with its own full stack trace, request context (method, path, status), user, agent, and release stage.
• Use Case: Shows the spread across users, payloads, and environments — "is this everyone, or one browser on staging?"
• Sample Question: "Show me 5 sample events of error abc123 from the last 6 hours."
• Inputs: project_id (required), error_id (required), time_dur (required), timeStart, timeEnd, limit (default 5).

get_error_trends

• Description: Error occurrences bucketed over time for an APM or Browser project, so you see when errors spiked rather than only which errors exist.
• Use Case: Establishes onset. Anchors "did this start with the deploy?" to a real timestamp.
• Sample Question: "Did errors spike in web-frontend after this morning's release?"
• Inputs: project_id (required), time_dur (required), timeStart, timeEnd.
• Next Steps: Feed the spike time into correlate_deploy_with_incident.

get_recent_transactions

• Description: Transaction groups (endpoints and background jobs) with per-endpoint average, minimum, and maximum response time, Apdex, request counts, failure count, and failure rate.
• Use Case: Finds the slow or failing endpoint, and unlike get_apm_metrics it includes background jobs and failed requests.
• Sample Question: "Which endpoint in order-service is slowest today?"
• Inputs: project_id (required), time_dur (required), timeStart, timeEnd, transaction, version, release_stage, limit (default 20).
• Next Steps: Take the slow endpoint into get_transaction_spans.

get_transaction_spans

• Description: Where time goes inside one transaction: the slowest spans classified as Database, External (downstream API), or Internal-App, with response time, call count, and percentage of total time.
• Use Case: Turns "this endpoint is slow" into "this endpoint is slow because of this query".
• Sample Question: "Why is POST /checkout slow?"
• Inputs: project_id (required), transaction_id (required), time_dur (required), timeStart, timeEnd.
• Next Steps: If spans come back empty, use search_traces and get_trace_detail — distributed traces still tell the story.

get_apm_database_calls

• Description: The APM Databases view: which database engines your application talks to (PostgreSQL, MySQL, Redis, MongoDB, and so on) with average latency, call volume, and share of database time, plus the slowest database operations.
• Use Case: Database performance from the application's perspective — the calls your code actually makes.
• Sample Question: "How are order-service's database calls performing?"
• Inputs: project_id (required), time_dur (required), database, limit, order_by (responseTime, throughput), timeStart, timeEnd.
• Next Steps: For the database instance's own perspective (connections, locks, EXPLAIN plans) use Database Monitoring.

get_apm_timeseries

• Description: Response time, throughput, and HTTP failure count bucketed across the range, plus a window summary. This is the data behind the APM dashboard line charts.
• Use Case: Shows shape over time — a step change, a slow drift, or a spike — instead of a single average.
• Sample Question: "How did order-service's response time trend over the last 24 hours?"
• Inputs: project_id (required), time_dur (required), timeStart, timeEnd, transaction.

get_api_analytics

• Description: Breaks a service's real request traffic down by a chosen dimension — country, endpoint path, customer, IP, browser, OS, device, domain, host, or request name — with request count, average duration, and failure count and rate per row.
• Use Case: Answers "who is this traffic?" questions: which customer is hammering the API, which country sees the worst latency, which path carries the failures.
• Sample Question: "Which country has the highest failure rate on the API this week?"
• Inputs: project_id (required), time_dur (default 1d), timeStart, timeEnd, group_by (country, browser, os, device, path, domain, hostname, ip, requestName, companyId; default country), limit (default 10).

get_recent_deployments

• Description: Recent deployment markers for a project — version, who deployed, when, environment, repository, and revision.
• Use Case: The "what is in prod, and when did it ship?" lookup that starts most change-correlation work.
• Sample Question: "What did we deploy to order-service recently?"
• Inputs: project_id (required), limit (default 5). This tool takes no time parameter; it returns the most recent markers.

correlate_deploy_with_incident

• Description: Answers "what changed?". Given an incident timestamp (or now), it lists deployments in the lookback window and reports the error delta before versus after each one.
• Use Case: The first SRE question during an incident, answered with a number instead of a guess.
• Sample Question: "Errors spiked at 14:20 — did a deploy cause it?"
• Inputs: project_id (required), incident_time, lookback_minutes (default 60), compare_window_minutes (default 15).

update_error_status

• Description: Changes one error group's status to Resolved (mark fixed), Ignored (mute, stops notifications), or Open (reopen). The API equivalent of resolving or ignoring an error in the Atatus UI.
• Use Case: Lets an assistant or an external system close out error state without anyone opening the dashboard.
• Sample Question: "Mark error abc123 in checkout-service as resolved."
• Inputs: project_id (required), error_id (required), status (required; Resolved, Ignored, or Open).

analyze_slow_transactions

• Description: Ranks transactions by two impact lenses in one call: highest total time spent (average response time × throughput — the endpoints actually burning your latency budget) and long-tail outliers (max ÷ average — endpoints where most calls are fast but some are terrible).
• Use Case: Separates "slow but rarely called" from "fast but called constantly", which is where optimisation effort actually pays.
• Sample Question: "Where should I focus optimisation effort in order-service?"
• Inputs: project_id (required), time_dur (required), timeStart, timeEnd, top (default 5), sample_size (default 50, maximum 50).
• Coverage: both rankings are computed over at most sample_size transactions (50 at most). Ranking B only considers endpoints with a max/avg ratio of 3 or more and at least 10 requests, so it can legitimately return nothing when latency is consistent.
• Next Steps: Take the recommended endpoint into get_transaction_spans.

Browser Monitoring

Real User Monitoring for web applications. These tools need a Browser project ID from list_projects, not an APM one.

get_web_vitals

• Description: Core Web Vitals for a Browser project — LCP, FCP, INP, FID, CLS, and TTFB — each with its average score, the Good / Needs-Improvement / Poor distribution, and an overall status.
• Use Case: Core Web Vitals are Google's user-experience and search-ranking signals, so this is the headline front-end quality number.
• Sample Question: "What are the Core Web Vitals for the marketing site this week?"
• Inputs: project_id (required), time_dur (required), timeStart, timeEnd, search (page URL filter).
• Next Steps: If a vital is Poor, use get_page_performance to find which pages drag it down.

get_page_performance

• Description: Per page URL: load time, render, network, and DOM time, Apdex, error count, and percentiles from P50 to P99.
• Use Case: Turns a bad site-wide vital into a specific slow page, with the tail latency real users actually experience.
• Sample Question: "Which pages are slowest for real users, and what's the P95?"
• Inputs: project_id (required), time_dur (required), timeStart, timeEnd, search, limit (default 10).

get_ajax_performance

• Description: AJAX and XHR performance per endpoint — response time, callback time, throughput, error rate, and data transferred.
• Use Case: Separates "the page is slow" from "the API the page calls is slow", which is the usual front-end versus back-end argument.
• Sample Question: "Which front-end API calls are slow or failing?"
• Inputs: project_id (required), time_dur (required), timeStart, timeEnd, search, method, limit (default 10).

get_browser_errors

• Description: The distinct JavaScript errors hitting real users, grouped, each with its message, total occurrences, affected user count, error type or class, source file:line, and first and last seen.
• Use Case: The Browser equivalent of the APM error inventory: what is actually breaking in users' browsers, ranked by impact.
• Sample Question: "What JavaScript errors are our users hitting today?"
• Inputs: project_id (required), time_dur (required), timeStart, timeEnd, order_by (occurrences, recent, first_seen; default occurrences), group_by (message, source; default message), limit (default 20), page, detail (full, compact). Filters: message, page_url, url, error_class, file, browser, os, device, country, app_version, user, plus exclude_message, exclude_page_url, exclude_url, exclude_class, exclude_file.
• Next Steps: Take the error_id into get_browser_error_details for stack traces.

get_browser_error_details

• Description: Drills into one JavaScript error and returns its individual real-user occurrences — each with the full JS stack trace (file, line, method), the browser, OS, device, and connection, the page URL, the affected user, and geography.
• Use Case: The "where does this actually break, and for whom?" tool. This is where front-end stack traces live.
• Sample Question: "Show me the stack trace for this TypeError and which browsers it hits."
• Inputs: project_id (required), error_id (required), time_dur (required), timeStart, timeEnd, order_by (recent, oldest; default recent), limit (default 20), page. Filters: page_url, url, browser, os, device, country, app_version, user, plus exclude_url, exclude_page_url.

Mobile Monitoring

Real User Monitoring for iOS and Android apps. These tools need a Mobile project ID from list_projects.

get_mobile_summary

• Description: The health entry point for a mobile app: crash-free rate for this window against the previous one, plus sessions, views, crash, non-fatal-error and ANR counts, ANR rate, and app vitals such as refresh rate, memory, and slow frames.
• Use Case: The mobile equivalent of get_service_health_summary — one call for "is the app OK?".
• Sample Question: "What's the crash-free rate for the iOS app this week?"
• Inputs: project_id (required), time_dur (default 7d), timeStart, timeEnd.

get_mobile_crashes

• Description: The top fatal crashes, grouped and ranked by occurrences, each with affected users, top device, OS versions, app versions, and an error_id for drilling in.
• Use Case: "What is crashing my app, and how badly?" ranked by real user impact.
• Sample Question: "What are the top crashes in the Android app?"
• Inputs: project_id (required), time_dur (default 7d), timeStart, timeEnd, limit (default 20).
• Next Steps: Take the error_id into get_mobile_crash_details for the stack trace.

get_mobile_errors

• Description: The top non-fatal errors — handled exceptions that hurt the experience without killing the app — grouped and ranked by occurrences, with affected users, top device, OS and app versions, and an error_id.
• Use Case: The damage that never shows up in a crash-free rate but still drives churn and bad reviews.
• Sample Question: "Which non-fatal errors are most common in the iOS app?"
• Inputs: project_id (required), time_dur (default 7d), timeStart, timeEnd, limit (default 20).

get_mobile_crash_details

• Description: Detail for one crash or non-fatal error: the full stack trace, error class and message, platform, impact (occurrences, users, sessions affected), first and last seen with app versions, and OS.
• Use Case: "Show me this crash — where does it break and how bad is it?"
• Sample Question: "Show me the stack trace for this crash."
• Inputs: project_id (required), crash_id (required), time_dur (default 30d), timeStart, timeEnd.

get_mobile_version_health

• Description: Release health for one app version: fatal crashes and non-fatal errors that version is producing, users and sessions it reached, and the top issues on that release, each with an error_id.
• Use Case: The post-release check — "is v2.3.1 worse than what it replaced?" — and the input to a rollback decision.
• Sample Question: "How is v2.3.1 doing compared with the last release?"
• Inputs: project_id (required), version (required), time_dur (default 7d), timeStart, timeEnd.

get_mobile_sessions

• Description: Real-user sessions, each with duration, screens visited, errors and crashes hit, tap or action count, frustration signals such as rage taps, and the first and last screen.
• Use Case: Finds the sessions worth replaying — by default the ones with the most errors.
• Sample Question: "Show me the worst user sessions in the app today."
• Inputs: project_id (required), time_dur (default 7d), timeStart, timeEnd, order_by (most_errors, recent, longest; default most_errors), limit (default 20).

get_mobile_session_details

• Description: Replays one session as a chronological timeline — every screen load, tap, slow frame, non-fatal error, and crash, in order, with the time offset from the start of the session.
• Use Case: Session replay as text: what the user actually did in the seconds before the crash.
• Sample Question: "What did the user do right before this session crashed?"
• Inputs: project_id (required), session_id (required), time_dur (default 7d), timeStart, timeEnd.

Kubernetes

get_kubernetes_overview

• Description: Cluster-wide summary with counts and percentages for Nodes, Pods (running, pending, failed), Containers, Deployments, DaemonSets, StatefulSets, Services, PVs, PVCs, and HPAs.
• Use Case: The first Kubernetes call for any "is the cluster OK?" question.
• Sample Question: "Give me an overview of the prod cluster."
• Inputs: time_dur (required), cluster, namespace.
• Next Steps: Follow failures into get_kubernetes_unhealthy_workloads or list_kubernetes_pods.

list_kubernetes_pods

• Description: Pods with status, node, CPU, memory, restart count, and owning workload (Deployment, DaemonSet, Job, CronJob, or ReplicaSet).
• Use Case: Finds crashing or restarting pods and shows what is running in a namespace.
• Sample Question: "Any pods in CrashLoopBackOff in namespace payments?"
• Inputs: time_dur (required), cluster, namespace, order_by (status, pod, cluster, namespace, age, ready, cpuUsage, memoryUsage, containerRunning, startTime), limit (default 20), page.
• Next Steps: Take the pod into get_pod_details, then get_pod_logs.

get_kubernetes_pending_pods

• Description: Pods stuck in Pending phase with their (often empty) node assignment and creation time.
• Use Case: Isolates scheduling failures from application failures.
• Sample Question: "Are any pods stuck pending?"
• Inputs: time_dur (required), cluster, namespace.
• Next Steps: Use get_kubernetes_events for the FailedScheduling reason and list_kubernetes_nodes for capacity.

list_kubernetes_nodes

• Description: Nodes with capacity (CPU and memory, pod allocatable and capacity), age, and health conditions (Ready, MemoryPressure, DiskPressure, PIDPressure) merged into one call.
• Use Case: Answers "is the cluster full?" and "which node is under pressure?".
• Sample Question: "Which nodes are under memory pressure?"
• Inputs: time_dur (required), cluster, order_by (node, name, clusterName, status, cpuUsageNanocores, memoryUsageBytes, cpuPercentage, memoryPercentage, statusUnschedulable, podAllocatableTotal, podCapacityTotal, startTime, age), limit (default 20), page.
• Next Steps: Use list_pods_on_node to find the pod consuming the node.

list_kubernetes_deployments

• Description: Deployments with desired, available, unavailable, and up-to-date pod counts, plus age.
• Use Case: Confirms whether a rollout completed or is stuck with missing replicas.
• Sample Question: "Did the payments rollout finish?"
• Inputs: time_dur (required), cluster, namespace, order_by (free-form sort field, no fixed list), limit (default 20), page.

get_kubernetes_events

• Description: The Kubernetes event stream — warnings, errors, and state changes across pods, nodes, and other objects.
• Use Case: The reason behind a failure: scheduling failures, container crashes, image-pull errors, OOM kills.
• Sample Question: "Why did the checkout pod fail to start?"
• Inputs: time_dur (required), cluster, namespace, kind, name, limit (default 50), page.
• Next Steps: When events run to dozens, use analyze_kubernetes_event_storm for the shape instead.

get_kubernetes_unhealthy_workloads

• Description: One call returning the unhealthy Deployments, DaemonSets, and StatefulSets together.
• Use Case: The cross-workload sweep — "what is broken anywhere in the cluster?"
• Sample Question: "Are there any unhealthy Kubernetes workloads right now?"
• Inputs: time_dur (required), cluster, namespace.

get_pod_details

• Description: The full picture for one pod in a single call: status, node, cluster, namespace, CPU, memory, restart count, age, and owning workload, plus that pod's recent events (FailedScheduling, OOMKilled, CrashLoopBackOff, probe failures, ImagePullBackOff).
• Use Case: The kubectl describe pod equivalent, without cluster access.
• Sample Question: "Give me the full picture of pod checkout-7d9f-x2k."
• Inputs: pod_name (required), namespace, cluster, time_dur (default 1h).
• Next Steps: Follow with get_pod_logs.

list_pods_on_node

• Description: The pods running on one node, sorted by CPU or memory.
• Use Case: Finds the noisy neighbour on a hot node.
• Sample Question: "Which pods are eating node ip-10-0-3-14?"
• Inputs: node_name (required), time_dur (required), cluster, order_by (cpuUsage, memoryUsage, restartCount, age; default cpuUsage), limit (default 15).

get_pod_logs

• Description: Log lines for a specific pod, filterable by level and free-text query.
• Use Case: The natural next question after a pod is found in CrashLoopBackOff or OOMKilled: what did it log before it died?
• Sample Question: "Show me the error logs from pod checkout-7d9f-x2k."
• Inputs: pod_name (required), namespace, cluster, level (error, warn, info, debug), query, time_dur (default 30m), timeStart, timeEnd, limit (default 100).

analyze_kubernetes_event_storm

• Description: Groups Kubernetes events by reason (FailedScheduling, OOMKilled, ImagePullBackOff, CrashLoopBackOff, BackOff, NodeNotReady, and so on) and returns the top reasons with affected pod and object counts.
• Use Case: Turns a wall of fifty-plus events into "this is mostly one scheduling problem".
• Sample Question: "The prod cluster is noisy — summarise the event storm."
• Inputs: time_dur (required), cluster, namespace, top (default 5), sample_size (default 100, maximum 100).
• Coverage: reasons are counted from the most recent sample_size events (100 at most). The response compares that against the true window total and says explicitly when you are looking at a sample.
• Next Steps: Use get_kubernetes_events filtered to the dominant reason, then get_pod_details.

Infrastructure

get_infrastructure_overview

• Description: Fleet summary: host counts by state (healthy, warning, critical, offline), hot and under-utilised servers, container and process counts, and fleet-average CPU, memory, and disk.
• Use Case: The first infrastructure call for "is my infra OK?".
• Sample Question: "How's the fleet looking?"
• Inputs: time_dur (required), hostname.

list_infrastructure_hosts

• Description: Monitored hosts (VMs, bare metal, Kubernetes nodes) with CPU percentage, memory used and total, disk used and total, and active or inactive status, plus a fleet summary header.
• Use Case: Finds the hot host, or the one that stopped reporting.
• Sample Question: "Which hosts are inactive?"
• Inputs: time_dur (required), hostname, limit (default 20), page.
• Next Steps: Drill into a hot host with list_host_processes.

get_infrastructure_checks

• Description: Up, down, or unknown status for agent self-checks, process monitors, and integration (plugin) checks.
• Use Case: Answers "is the agent reporting on this host?" and "did the Redis or Nginx integration stop?".
• Sample Question: "Is the Redis integration reporting on cache-prod-1?"
• Inputs: time_dur (required), hostname.

get_infrastructure_metrics

• Description: Queries infrastructure metrics directly — CPU, memory, disk, network, load, and process metrics for hosts.
• Use Case: The escape hatch when the summary tools do not carry the specific metric you need.
• Sample Question: "Show me network throughput on app-prod-1 for the last 6 hours."
• Inputs: time_dur (required), metrics (required, an array of metric names), group_by, hostname, interface_filter (all, physical; default physical).

list_containers

• Description: Docker containers across monitored hosts with name, image, host, status, CPU percentage, memory RSS, network I/O, and start time.
• Use Case: Finds the container consuming resources, or confirms which image is running where.
• Sample Question: "Which containers are using the most CPU?"
• Inputs: time_dur (required), hostname, container_name, image_name, order_by (cpuUsageNodePct, memoryRssBytes, netSentBytes, netReceivedBytes, startAt, containerName, status; default cpuUsageNodePct), limit (default 20), page.

get_container_events

• Description: The container lifecycle timeline — start, stop, restart, OOM kills, and exit codes.
• Use Case: Explains why a container restarted, after list_containers shows that it did.
• Sample Question: "Why did the worker container restart overnight?"
• Inputs: time_dur (required), container_name, hostname, image_name, limit (default 50), page.

list_host_processes

• Description: The top processes on a host with CPU usage, memory RSS, memory percentage, and open file descriptors.
• Use Case: Turns "this host is hot" into "this process is hot".
• Sample Question: "What are the top processes on app-prod-1 by CPU?"
• Inputs: hostname (required), time_dur (required), sort_by (cpu, memory; default cpu), limit (default 10).

get_host_inventory

• Description: Hardware and OS inventory per host: OS name and version, kernel, distribution, CPU model and core count, RAM, architecture, uptime, and boot time.
• Use Case: CVE and patching response ("which hosts run a kernel below X?"), compliance audits, and host-specific bug isolation.
• Sample Question: "Which OS versions are running across the fleet?"
• Inputs: hostname, time_dur (default 1d), limit (default 50), page.

Logs

get_logs

• Description: Searches raw log lines across the whole account — application, Kubernetes pod, Docker container, and host logs — with positive filters and exclusions.
• Use Case: The core log tool. It reaches every ingested source, so one call covers app, pod, container, and host logs.
• Sample Question: "Show me error logs from host Zenitsu in the last 7 days."
• Inputs: hostname, service, level (error, warn, info, debug), query, trace_id, status_class (2xx, 3xx, 4xx, 5xx), pod_name, namespace, cluster, exclude_query, exclude_hostname, exclude_service, time_dur, timeStart, timeEnd, limit (default 50).
• Next Steps: If the volume is too high to read, use analyze_logs for the recurring patterns instead.

analyze_logs

• Description: Groups log lines into recurring patterns and returns the top ones with counts. Variable parts — timestamps, UUIDs, IP addresses, hex IDs, quoted values — are masked out, so Connection refused to redis:6379 seen 47 times collapses into one pattern with a count of 47 instead of 47 separate lines.
• Use Case: Gives the shape of what is happening when get_logs would return more lines than you can read.
• Sample Question: "What's the most common error pattern in order-service today?"
• Inputs: service, hostname, level (error, warn, info, debug), time_dur (default 1h), top (default 5), sample_size (default 100, maximum 100).
• Coverage: patterns are computed from the most recent sample_size lines (100 at most), not the full window. The response states how many lines it analysed.
• Next Steps: Run get_logs with a query matching the pattern to read the raw lines.

Distributed Tracing

search_traces

• Description: Searches distributed traces across APM services, returning trace ID, total duration, status code, entry service, path, and method.
• Use Case: Finds the specific slow or failed requests worth opening.
• Sample Question: "Find all traces in checkout-service longer than 2 seconds in the last hour."
• Inputs: time_dur (required), project_id, status_code, min_duration, order_by (duration, timestamp, statusCode, serviceName, path; default duration), direction (desc, asc), span_type (all, parent, server; default parent), env, limit (default 20), page.
• Next Steps: Take a trace ID into get_trace_detail.

get_trace_detail

• Description: The full breakdown of one trace — request info, every database call with its query (slowest first), every remote-service call, error count, and a recomputed time breakdown.
• Use Case: Identifies which service or query owns the latency in a specific request.
• Sample Question: "Tell me everything about trace abc123."
• Inputs: trace_id (required), project_id (required), timestamp, time_dur.

get_slowest_spans

• Description: The slowest individual spans aggregated across all traces — the worst database queries, remote calls, and operations, without opening traces one at a time.
• Use Case: Finds the bottleneck that recurs everywhere, rather than the one bad request.
• Sample Question: "What's the slowest database operation in order-service today?"
• Inputs: project_id (required), time_dur (required), span_type (all, database, remote; default all), sort_by (duration, timestamp), direction (desc, asc), limit (default 20), page.

get_service_map

• Description: The service dependency map — every service with its upstream and downstream connections, request rate, error rate, and latency.
• Use Case: Spots cascading failures and shows what calls the failing service.
• Sample Question: "Show me the service map — anywhere with a high error rate?"
• Inputs: time_dur (required).
• Next Steps: For the richer cross-product graph, including infrastructure and Kubernetes placement, use Service Topology.

Database Monitoring

Database Monitoring (DBM) is a separate product from APM. These tools show the database's own perspective — connections, locks, plans — while get_apm_database_calls shows the calls one application makes.

list_databases

• Description: All monitored database instances, each with host, engine type, health, query throughput, average duration, and connection count.
• Use Case: The starting point for database work — which instance is unhealthy or slow.
• Sample Question: "Which of our databases is slowest right now?"
• Inputs: time_dur (required), timeStart, timeEnd, database_type (mysql, postgresql, mongodb, redis, mssql, oracle), host, order_by (throughput, durationAvg, lockDurationAvg; default throughput).

get_database_health

• Description: A one-call health card for a single instance: connection status and latency, query throughput, average query duration, lock contention, and row-scan efficiency, with a clear CONNECTED or DOWN verdict.
• Use Case: Answers "is this database up and healthy?" before you start blaming the application.
• Sample Question: "Is the orders postgres instance healthy?"
• Inputs: host (required), time_dur (required), timeStart, timeEnd, database_type (mysql, postgresql, mongodb, redis, mssql, oracle).

get_database_slow_queries

• Description: The slowest queries ranked by normalised signature — each row a query shape with average and total duration, call count, and engine.
• Use Case: The optimisation worklist. Highest average is the slowest per call; highest total is the biggest cumulative drain.
• Sample Question: "What are the slowest database queries this week?"
• Inputs: time_dur (required), timeStart, timeEnd, limit (default 10), dbType, orderBy (durationAvg, durationTotal, count; default durationAvg).
• Next Steps: Take the signature into get_database_query_details.

get_database_query_details

• Description: Deep detail for one query signature: its EXPLAIN or execution plan, keys examined, average duration, and captured sample executions.
• Use Case: Answers "why is this query slow?" and "is it actually using the index?".
• Sample Question: "Why is this query slow — does it use an index?"
• Inputs: query_signature (required), time_dur (required), timeStart, timeEnd.

Synthetics and Uptime

list_synthetic_checks

• Description: All synthetic monitoring checks — HTTP, SSL, ICMP, and browser — each with status (pass, fail, paused), uptime percentage, response time, and frequency.
• Use Case: The external-facing view: what customers can reach, from outside your network.
• Sample Question: "Are all our uptime checks passing?"
• Inputs: time_dur (default 1d).

get_synthetic_check_details

• Description: Full detail for one check — configuration, current status, response-time percentiles (average, P50, P90, P95, P99), and uptime statistics.
• Use Case: Drills into a specific monitor that is slow or flaky.
• Sample Question: "Why is the checkout uptime check slow?"
• Inputs: check_id (required), time_dur (default 1d).

get_synthetic_check_results

• Description: Individual run results, each with a timing breakdown (DNS, TCP, TLS, TTFB, download), HTTP status, and pass or fail.
• Use Case: Locates the latency inside the request — DNS versus TLS handshake versus server time.
• Sample Question: "Why is this check failing? Show me the recent runs."
• Inputs: check_id (required), time_dur (default 1d), result_status, limit (default 20), page.

get_availability_report

• Description: A daily uptime report for a check — availability percentage and downtime duration for each day in the range, up to 100 days.
• Use Case: SLA reporting, monthly uptime reviews, and client-facing availability numbers.
• Sample Question: "What was our uptime in March, day by day?"
• Inputs: time_start (required), time_end (required), check_id.

list_synthetic_incidents

• Description: Downtime incidents detected by checks, with the affected check, start time, duration, and status.
• Use Case: Outage history, and whether anything is down right now.
• Sample Question: "What went down this month, and for how long?"
• Inputs: status (Opened, Closed), check_id, search, limit (default 20), page. This tool takes no time-window parameter.

Service Topology

Flow View's cross-product dependency graph. Unlike get_service_map, which is APM-only, these tools span services, databases, hosts, and Kubernetes placement in one graph.

search_topology_entities

• Description: Resolves a human name from your question — "checkout", "payments-db", "the postgres host" — into an exact entityKey, plus its type, tier, and owning products.
• Use Case: Run this first. The other topology tools need an exact key, which a prompt never contains.
• Sample Question: "Find the checkout service in the topology."
• Inputs: name (required), entity_type, time_dur (default 1h), from, to.
• Next Steps: Pass the returned key into get_entity_topology.

get_entity_topology

• Description: The rooted map of one entity, in two modes. Structural (default) returns its neighbourhood both ways — what it calls or runs on, and what depends on it — plus infrastructure placement. Blast radius returns what is affected if it fails.
• Use Case: Answers "what does this depend on?" and, during an incident, "what else is going to break?".
• Sample Question: "If payments-db goes down, what breaks?"
• Inputs: entity_type (required), entity_key (required), mode (structural, blast_radius; default structural), hops, time_dur (default 1h), from, to.

get_product_topology

• Description: The account-wide graph for one product: apm (services and the databases, messaging, external, LLM, and cache systems they call), kubernetes, or infra.
• Use Case: The overview when the question is about a whole product rather than one named entity.
• Sample Question: "Show me the whole APM dependency graph."
• Inputs: product (required; apm, kubernetes, or infra), time_dur (default 1h), from, to.

query_topology_graph

• Description: A custom topology query for patterns the other three do not cover. You describe the shape as a small JSON structure (a start node plus optional segments) and the server composes the graph query, so an invalid query cannot be sent.
• Use Case: The escape hatch for unusual questions, such as multi-hop paths between two specific tiers.
• Sample Question: "Which hosts are two hops downstream of the checkout service?"
• Inputs: start (required, object), segments, rels, boundary, limit, time_dur (default 1h), from, to.

Time ranges

Most tools accept a time_dur parameter for the lookback window:

• Minutes: 1m, 2m, 3m, 5m, 10m, 15m, 30m, 60m
• Hours: 1h, 3h, 6h, 12h
• Days: 1d, 24h, 2d, 3d, 7d, 14d
• Weeks: 1w, 2w (normalised to 7d and 14d)
• Months: 1M, 2M, 3M (30d is normalised to 1M)
• Custom: set time_dur to custom and supply timeStart and timeEnd as ISO 8601 timestamps.

Example custom time range:

{
  "time_dur": "custom",
  "timeStart": "2026-04-15T00:00:00Z",
  "timeEnd":   "2026-04-22T00:00:00Z"
}

Individual tools accept different subsets of these tokens, and the accepted list is stated in each tool's own time_dur description in the live tools/list response. Two exceptions are worth knowing:

• get_availability_report uses time_start and time_end as ISO dates (for example 2026-03-01) rather than time_dur.
• The Service Topology tools accept from and to (ISO 8601 or epoch milliseconds) for a precise window, which overrides time_dur.

get_recent_deployments and list_synthetic_incidents take no time parameter at all. list_projects accepts time_dur, but it only affects the APM active-or-inactive verdict, never which projects are returned.

Response size and pagination

To keep responses readable and within context limits, tools return focused, capped results:

• Limit: most list tools accept a limit parameter to cap the row count.
• Pagination: paginated tools accept a page parameter to walk through subsequent batches.
• Automatic truncation: when results exceed the limit the response says so (for example "showing 20 of 134"). Large fields such as log lines and stack traces are truncated with a … (truncated) marker.

If you need more, narrow the query with filters or page through the results.

Not yet available

The following Atatus products have no MCP tools yet, and the assistant cannot answer questions about them:

• Alerts and Incidents — alert policies, alert rules, incident acknowledge and close, notification channels.
• SLOs — error budgets and burn-rate tracking.
• Maintenance windows.

Use the Atatus UI for these. Support is planned for a future release.