MCP Tools

Note: This page is generated from the tool declarations in the MCP server itself, so it cannot describe a tool that does not exist or omit one that does. 53 tools across 18 groups.

See MCP Server for setup, transports and worked examples.

All tools #

Orientation & configuration #

Start here: what exists, and how it is configured.

get_workspace_overview #

Start here. One call returns the buckets and environments this token can read, their recent traffic and error rates, and any recent deployments or incidents - enough to pick a bucket and a window for everything else.

Read-only.

list_buckets #

List the buckets this MCP token can read. Use get_workspace_overview instead when you also want recent traffic and error rates.

Read-only.

Takes no arguments.

list_environments #

List the environments configured for the account (e.g. production, staging, development). Traffic is separated by environment.

Read-only.

Takes no arguments.

list_redactions #

List the redaction rules that mask sensitive data (API keys, passwords, PII) before capture. Check these when a body or header you expected is masked.

Read-only.

Takes no arguments.

list_exclusions #

List the exclusion rules. A rule with action exclude stops matching requests from being captured (health checks, probes): check these when traffic you expected is missing entirely. A rule with an omit_* action keeps the request but does not log its request body, response body or both (the size is still recorded): check these when a body you expected is missing.

Read-only.

Takes no arguments.

list_endpoint_rules #

List the endpoint rules that decide how raw request paths are grouped into normalized endpoints (a match pattern on the path, and the endpoint name it becomes), in the order they are evaluated, with their priority, direction, hosts, whether each was written by hand or suggested, and whether it marks the requests it matches as long-lived connections (stream: left out of response-time metrics). Check these when an endpoint name in list_endpoints, drift or APM looks wrong or two endpoints should be one.

Read-only.

get_usage #

The account’s metered usage for the current billing period against its plan allowances - captured requests (inbound and outbound), host samples, MCP calls and the like - with whether each limit is a hard cap, plus counts of limited resources (workflows, WAF policies, tokens). Check this when traffic seems to be missing: a hard-capped allowance that is used up stops capture.

Read-only.

Takes no arguments.

Endpoints #

The endpoints an API serves and calls, and how each one is behaving.

list_endpoints #

List the normalized endpoints a bucket serves (“in”) or calls (“out”), with request count, error count, error rate and average latency for the window. Use it to learn the shape of an API before diving in, or to find the noisiest or slowest endpoints. The endpoint strings are the same ones drift, WAF and APM tools filter on.

Read-only.

get_endpoint_metrics #

Detailed metrics for one normalized endpoint: request count, p50/p95/p99/max latency, error rate, status-class mix, throughput and a per-interval timeseries. Prefer diagnose_endpoint for a health verdict against the previous window; use this for the raw shape of one endpoint.

Read-only.

Attention signals #

What ApiTraffic has already flagged as needing attention.

list_attention_signals #

List what ApiTraffic currently thinks needs attention on a bucket - error-rate spikes, error hotspots, latency and error regressions, slow endpoints, firewall blocks and open drift - most severe first. A good first call when asked “is anything wrong?”. By default only signals that are still visible (open, acknowledged, or with an expired snooze) are returned.

Read-only.

Diagnosis #

Task-shaped tools that answer a question rather than returning rows.

diagnose_endpoint #

One-call health verdict for a bucket or a specific endpoint: status-code breakdown, latency percentiles, comparison against the preceding window, the failure clusters driving errors, correlated deployment/incident markers, and sample request sids to inspect. Use this before reaching for the individual metrics tools.

Read-only.

compare_windows #

Before/after comparison - the regression primitive. Give it a pivotTime (e.g. a deploy timestamp from list_events) or two explicit windows, and it returns metric deltas, which failure clusters were introduced or resolved, and the endpoints that moved most.

Read-only.

get_error_clusters #

Group failing requests into distinct problems instead of a flat list. Requests are clustered by normalized endpoint pattern, method and status, so /orders/1/refund and /orders/2/refund count as one issue. Each cluster carries occurrence counts, first/last seen, sample request sids and optionally the error message behind it.

Read-only.

get_fix_prompt #

Generate a paste-ready prompt for an AI coding agent (Cursor, Claude Code, Copilot) to root-cause and fix a failing API request in the customer’s own code. It combines the request/response, a normalized error signature, and the git deploys/commits that landed just before the failure (when a repo is connected). Provide either a requestSid, or an endpoint/time window to pick the most recent failure from.

Read-only.

get_waterfall_prompt #

Generate a paste-ready prompt for an AI coding agent about where one request spent its time and how to make it faster. It carries every span (database, cache, outbound HTTP, queue) in start order with its offset, duration, share of the request, code location and call stack, the commit that was deployed, and precomputed facts: time per dependency, idle gaps, and repeated operations with whether they ran sequentially (candidates to parallelize, batch or cache). Captured parameter values are never included. Find a slow request with search_requests (minDurationMs) or get_trace.

Read-only.

Health digest #

How a day or a week went: the numbers and the news the daily and weekly digest email is built from.

get_health_digest #

The daily or weekly API health summary the digest email is built from: per environment and bucket, requests, latency (avg, p95, p99), error rates and availability against the previous period, a status (incident, attention, healthy, no_traffic, not_stored, retention_cut, unavailable), and what was new: incidents, drifts, slow endpoints, new error types, deploys and new endpoints. Same numbers as the email for the same timezone and period. At most 25 buckets are read at once: with more, the busiest are shown (in the period, or the last 7 days for a period older than 30 days; past retention, those with a stored digest first) and truncated gives the counts, the ranking window and storedFirst. Use it to answer “how did last week go?”.

Read-only.

Drift #

Changes between an endpoint’s learned baseline and its current traffic.

list_drift_findings #

List changes ApiTraffic detected between an endpoint’s learned baseline and its current traffic - removed or retyped response fields, new error rates, latency shifts, new downstream dependencies, endpoints appearing or going quiet. Use this to answer “what changed in this API?” - including silent changes that never produced an error.

Read-only.

get_drift_finding #

Full detail for one drift finding: the structured before/after diff, the baseline it was measured against, and the sids of the captured requests that evidence it. Pass those sids to get_request_detail to read the actual payloads.

Read-only.

get_drift_prompt #

Generate a grounded, paste-ready prompt for investigating one drift finding in the customer’s own code. It combines the finding diff, the learned baseline, the evidencing request sids and the git deploys/commits that landed just before the drift began (when a repo is connected). Returns the prompt text - the same one the ApiTraffic UI shows on the finding.

Read-only.

get_drift_health #

Whether drift detection is actually watching a bucket, and why the finding list looks the way it does: the scan state with a one-line explanation, when it last ran and runs next, how many endpoints it discovered and diffed, how many baselines are active versus still learning, and how many findings are open. Call this before reading an empty list_drift_findings as “nothing changed”.

Read-only.

Requests #

Individual captured requests and responses.

search_requests #

Search captured HTTP requests using the ApiTraffic criteria DSL plus common shortcuts. Returns compact one-line summaries; call get_request_detail for headers and bodies. Read the apitraffic://criteria-dsl resource for the full grammar.

Read-only.

get_errors #

List individual failing requests (status >= 400) in a window. Prefer get_error_clusters when you want to know what is broken; use this when you need specific request sids to inspect.

Read-only.

get_request_detail #

Full detail for one request: headers, query params, request/response bodies and timings. Bodies are truncated to maxBodyBytes so a large payload cannot flood your context.

Read-only.

Collections #

Named sets of requests your team saved while debugging.

list_collections #

List the request collections your team has saved in a bucket - named sets of captured requests kept as evidence while debugging - with how many requests each holds. Read these before starting an investigation from scratch; get_collection returns the requests in one.

Read-only.

get_collection #

One saved collection with its requests: each request sid with the name it was saved under and, while the request is still retained, its method, path and status (looked up for the newest 25). Pass a sid to get_request_detail or replay_request to work with it.

Read-only.

Saved views & workflows #

The team’s named request filters, and the automations they trigger.

list_saved_views #

List the saved views (named request filters) your team built in a bucket, each with its criteria DSL string and whether a workflow is attached. Pass a view’s criteria as the query to search_requests to read exactly the traffic the team means by that name.

Read-only.

list_workflows #

List the workflows (automations such as alerts or tickets) configured in a bucket: name, whether enabled, the external system that runs them, the environments they run in and how many saved views trigger them. Use it to explain why an alert fired, or to check what happens when matching traffic arrives.

Read-only.

Tag dimensions #

The tag keys requests carry (such as a customer id), and the catalogue that names their values.

list_dimensions #

List the tag keys the account’s SDKs send (such as customerId or plan): share of requests carrying each, distinct values, classification (none, pseudonymous, personal, secret), which key identifies customers, and which keys are promoted to fast reports, plus suggestedToPromote: unpromoted keys the account’s saved reports and dashboards would read from pre-aggregated data once promoted, with how many of each (pass includeSuggestions false to skip that when only the keys are needed). Use it to learn what context requests carry before grouping or filtering by a tag.

Read-only.

get_dimension_values #

Look up the customer catalogue of a tag key: each value’s readable label and attributes (for example org_8f2a is “Acme Corp”, plan enterprise, region eu). Search by value or label to resolve a customer name to its id, or an id to its name.

Read-only.

Reports #

Custom reports: traffic grouped by any field, tag or customer attribute, and the team’s saved reports.

run_report #

Run a custom report: group requests by up to two dimensions (a request field such as endpoint or host, tag:<key> such as tag:customerId, attr:<key>:<attribute> from the customer catalogue, the firewall decision: waf_action, waf_policy, waf_rule, waf_matched, or the client: ip_address, country), compute metrics per group (count, error_rate, p95, distinct:tag:<key>, sum:ai_input_tokens, waf_blocked_count, …), optionally as a series and against an earlier period. Answers “which customers call us most”, “error rate by plan”, “LLM tokens by customer”, “which customers does the firewall block”, “which IPs does it block”, “traffic by country”. With source “spans” it counts APM operations inside requests instead (needs APM; at most 7 days; no tags, firewall or client dimensions): group by type, fingerprint (operation), name, op, target, system, db, host (peer), out_target, out_status_class, error_class, error_type, endpoint, call_site, service_version, instance_sid; metrics count (calls, weighted by sampling), error_count, error_rate, total_time, avg, p50-p99, max, requests, calls_per_request (N+1), out_client_error_count, out_server_error_count, out_no_response_count, sum:rows, avg:rows. Answers “slowest database queries”, “outbound time by vendor”, “N+1 queries by endpoint”. Results say whether they are exact or approximate (meta.dataset says which source); for a request report, meta.promotable names a tag key whose promotion would make it read fast pre-aggregated data (also given when it is refused for reading over 31 days of stored requests; never for firewall or client reports, which only stored requests can answer).

Read-only.

list_saved_reports #

List the reports the team saved (shared with the account, and the connected person’s own private ones): name, description, how each is drawn, its folder and its definition. Run one with run_saved_report.

Read-only.

run_saved_report #

Run one of the team’s saved reports, optionally over another time range or with an extra filter (ANDed with the report’s own, e.g. one customer: tag:customerId == “org_8f2a”).

Read-only.

Metrics #

Raw series and summary numbers.

get_metrics #

Totals for a window: request count, average response time, error count and blocked count.

Read-only.

get_throughput #

Request throughput over time, broken down by status class (2xx/3xx/4xx/5xx).

Read-only.

get_response_times #

Response time percentiles (p50/p95/p99) and averages over time.

Read-only.

APM #

Inside the service: slow queries and calls, their latency over time, what got slower after a deploy, where request time goes, and distributed traces.

slow_operations #

Rank the operations inside the service - database queries, cache and Redis calls, outbound HTTP, queue and RPC calls - by total time, p95/p99 latency, call count, calls per request (N+1 detection) or error rate. Each operation carries its fingerprint (use it with operation_trend), latency in ms and the share of the window that was read. Statement text is omitted unless includeStatementText is set and the account has it enabled.

Read-only.

operation_trend #

p50/p95/p99 latency, calls and errors over time for ONE operation (fingerprint + fpVersion from slow_operations) or ONE endpoint (endpoint + method). Use it to see when a slowdown started and whether it lines up with a deploy.

Read-only.

regressions_since_deploy #

What got slower after a deploy: operations (default) or endpoints ranked by how much their p95 shift costs (p95 delta x calls after), comparing an equal span before and after the deploy time. The deploy is pivotTime, or the newest deployment event (matching version when given). Each row has before/after p95 in ms and a regressed verdict; rows with too little data say so.

Read-only.

get_time_breakdown #

Where request time goes - database, cache, outbound HTTP, queue and the app itself - as milliseconds and a share of total, with request count, errors and p50/p95/p99. groupBy “none” (default) gives the bucket or one endpoint; groupBy “endpoint” ranks endpoints by the total time they consume, each with its own split. Use it to decide whether a slow API is waiting on the database, a third party, or its own code, before slow_operations narrows it to one query.

Read-only.

get_trace #

Every captured request that belongs to one distributed trace, in time order - the inbound call that started it and each downstream and upstream call it made across your services - with endpoint, status, duration and span count. Pass a requestSid (the trace id is read off it and the hour either side is searched) or a traceId with a window. Use it to find which hop in a chain failed or was slow.

Read-only.

Hosts #

The servers behind your API and how loaded they are.

list_hosts #

The servers (SDK processes) reporting host telemetry in a window, with each one’s latest CPU, event-loop delay, heap and memory use, in-flight requests, service version and git sha - including servers that stopped reporting, with when they went quiet - plus fleet-wide averages and peaks. Use it to tell a capacity or runtime problem from a code problem when latency rises.

Read-only.

Firewall #

What the WAF inspected, matched and blocked, and the requests behind it.

get_waf_overview #

Firewall (WAF) activity for a window: requests inspected, matched, blocked and would-block (monitor mode), match and enforcement rates, anomaly-score stats, and the busiest rules with their message and category. Use it to answer “is the firewall blocking legitimate traffic?” or “are we under attack?”, then list_waf_matches for the requests themselves.

Read-only.

list_waf_matches #

The requests the firewall (WAF) matched, newest first: method, path, normalized endpoint, status, anomaly score, action taken (block / would-block / tag), the deciding rule and every contributing rule id. Filter by rule, category, action, policy or endpoint; pass a sid to get_request_detail to see the payload that tripped it.

Read-only.

list_waf_policies #

List the WAF policies that apply to this token’s buckets: mode (block / monitor), paranoia level, anomaly threshold, managed ruleset, the buckets and environments each covers, and how many custom rules, disabled rules and exclusions it carries. get_waf_policy returns the full configuration.

Read-only.

Takes no arguments.

get_waf_policy #

The full configuration of one WAF policy: mode, thresholds, managed ruleset, disabled rules, rule exclusions (paths a rule is switched off for), custom rules, IP/geo lists, rate limits, egress and behaviour settings, and any warnings about how SDKs enforce it. Use it to explain why a request was or was not blocked.

Read-only.

get_waf_rule #

What one WAF rule id means: its message, category, severity, anomaly score, paranoia level, the parts of the request it inspects, its operator and transforms, the ruleset versions that carry it, and for managed rules a plain-language explanation of what it catches and what legitimate traffic it can match, plus an overview of the attack category, its impact and how to fix it in the application. With a policySid, also whether that policy disables it or excludes it for some paths, and custom rules defined in that policy, with whether such a rule runs (enabled: false for a rule turned off, or a stored criteria rule sent to your servers turned off) and the policy’s warnings about it. Use it on the ruleId from list_waf_matches or get_waf_overview.

Read-only.

Replay #

Turn a captured request into something you can run yourself.

replay_request #

Turn a captured request into a runnable replay you execute yourself - curl, raw HTTP, or fetch - optionally retargeted at localhost or staging. ApiTraffic does not re-send the request for you, so a replayed write cannot duplicate a production side effect. Credential headers are emitted as $ENV_VAR placeholders, never live values.

Read-only.

Events & deploys #

Deployment and incident markers, to correlate with traffic changes, and the code that was deployed.

list_events #

List event markers (deployments, incidents, config changes, scale events) so you can correlate them with traffic changes.

Read-only.

create_event #

Record an event marker (deployment, incident, config change) so later traffic changes can be correlated with it. This writes to the account.

Writes to your account.

get_deployed_code #

Which repository, branch and commit was running at a moment - or when a given request was captured - taken from the deploy markers the git integration or your CI wrote, with a URL template for linking to files at that exact commit, plus the deploys (and their commits) that landed in the day before. Use it to read the code that actually served a failing request rather than whatever is on main now.

Read-only.

Documentation #

Search these docs. The only tools not scoped to your account.

search_docs #

Search the ApiTraffic documentation and return the matching sections with their text, so you can answer setup, configuration and API questions from the real docs instead of guessing. Covers the quickstart, SDK integration guides and configuration, the request log and search syntax, APM, the firewall, redaction and exclusions, collections and sharing, workflows, MCP, git integrations, account administration, account activity webhooks and the full REST API reference.

Read-only. Reads the public documentation site, not your account data.

get_doc_page #

Return the full text of one documentation page, plus its headings. Use after search_docs when a section excerpt is not enough context.

Read-only. Reads the public documentation site, not your account data.

list_doc_pages #

List every documentation page with its title, path and area. Cheap orientation when you do not yet know what to search for.

Read-only. Reads the public documentation site, not your account data.

Takes no arguments.