Tools provided
Tools the agent exposes — your AI client calls them automatically when it needs them.
- review_infra_change — Review a parsed Terraform/Helm plan for structural risk: which resources have drifted from the committed config, what the change does to the monthly bill, and how much of that bill figure is actually covered by priced rows. Returns findings, KPIs and a ready-to-post PR comment. Security and least-privilege are not reviewed here.
- detect_drift — List the resources in a supplied plan whose live state has drifted from the committed config, with the caller's own drift note for each. Reports how many rows actually carry a drift verdict, so a plan where drift was never measured is never reported as a plan with no drift.
- estimate_infra_cost — Estimate forward from a planned change: sum the per-resource monthly figures you supply into a before/after/delta, name the resources that moved it most, and report how many rows carried no price at all. Nothing is priced here — the arithmetic is on your numbers. For splitting a bill you have already received, use allocate_cloud_spend.
- triage_cluster — Triage a cluster state dump you paste: group unhealthy pods by workload, say what each status is consistent with, name the evidence that would confirm it, and return the order to look in — worst and widest first. Reports what the dump could not answer instead of inferring cluster state.
- plan_scaling — Size your workloads for a load you name: proposed replica counts, CPU and memory requests checked against observed usage, and the monthly cost of the change. Every threshold and formula is returned with the proposal. Cost is computed only for workloads that supplied a per-replica figure; the rest are listed as unpriced rather than guessed.
- check_reliability — Check supplied workload definitions for single points of failure, missing readiness and liveness probes, disruption-budget gaps and unbacked state, ordered worst first and corroborated against any outage history you supply. A field your dump does not state is reported as not stated, never assumed absent.
- allocate_cloud_spend — Allocate a cloud bill you have already received across your customers: cost-to-serve, gross profit and gross margin per account, a per-plan roll-up, the loss-making accounts worst first, and the bill lines your allocation key had no basis for. The allocation key is stated in the report so next month's split is comparable. For projecting a change you have not made yet, use estimate_infra_cost.
- write_postmortem — Turn an incident record into a blameless postmortem: duration and the evidence behind it, severity, a five-why chain answered only where the record answers it, and action-item ownership. An incident that crosses midnight is measured rather than dropped, an inferred duration is labelled as inferred, and an unanswered why step is returned as a question instead of being written for you.
- find_incident_patterns — Read a period of incidents and report what repeats: the categories driving the count, how long each takes to resolve, the systems they hit, and the vital few that together account for 80 percent. An incident with no recorded resolution time counts toward frequency and is excluded from the average rather than treated as zero, and the report says how many were excluded.
- triage_logs — Cluster raw log text into ranked error signatures: what repeats, how severe it is, how many times it occurred, and the exact line numbers proving each one. Stack frames are attributed to the first occurrence only, never merged across occurrences into a trace that never happened. A log longer than the read bound is reported as partial coverage rather than summarised as though it were whole.
- fetch_incident — Read one incident and its log from api.pagerduty.com into the exact shape write_postmortem takes: title, start, end, ordered timeline, affected services. An unresolved incident comes back with NO end time and no duration, never one measured against the moment you asked. The log read is bounded and says so when there is more history than it shows. Without a connected PD_API_KEY it returns nothing and names the credential - never an example incident.
- fetch_service_signals — Read one service's metric series and error logs from api.datadoghq.com for a window, and return the logs in the shape triage_logs reads. An interval Datadog has no data for is reported as a GAP, never as zero - a monitoring gap read as zero looks exactly like the crash this is meant to find. Log events with no timestamp are counted, not stamped with the time of the query. Every read bound is stated. Without both keys it returns nothing and names them.
- post_incident_note — Post a note onto a PagerDuty incident at api.pagerduty.com, under YOUR address, exactly as you wrote it. This is the one tool here that changes something outside your tool call, so it asks first. Nothing is ever posted without both PD_API_KEY and PD_FROM_EMAIL: with either missing it refuses and says so, and there is no acknowledgement for a note that was not written.
- correlate_change — Place what shipped against when the incident began, and rule out what the error's own first occurrence excludes. It NAMES NO CAUSE and ranks nothing - a change landing before an outage is not evidence it caused one, and the usual triggers ship no code at all. What it proves is exclusion: if the error was already happening before a change shipped, that change did not introduce it. Send no errorFirstSeen and it excludes nothing, and says so.
- compare_latency — Compare two latency windows you MEASURED. Each percentile is compared separately, because p50 and p95 move independently - a change that helps the median while hurting the tail is the ordinary shape of a cache. A percentile with fewer than 5 observations in its tail gets NO verdict. The improvement is WITHHELD, with the reason, when the two windows carried different load, when the error rate rose, or when only one run of each was supplied. Nothing is projected.
- check_metric_budget — Check what you measured against the limits YOU set. There is no threshold table and no default: the tool this replaces fell back to INFINITY for any metric it did not list, so an unlisted one always reported "ok" - which reads as a clean bill of health. Every limit must name the unit of work it is PER, because sixty queries per batch job and sixty per request are different facts wearing one number. A metric with no limit is NOT CHECKED, never within budget.
- run_full — Run every capability you supplied the input for, in registry order, and return one report. Capabilities whose input is missing are listed as skipped with the fields they need — never run against a fixture and never reported as zero.
- list_capabilities — List what this agent can do: every tool it advertises, what each one is for, and the arguments each one reads. Useful for discovery before the first call.
- plan_inputs — Plan the inputs for a tool: returns the questions to ask, the JSON schema of the arguments, and a ready-to-edit example. Every argument it names is an argument the tool actually reads.
- discover_intent — Understand your goal and co-design the exact input through clarifying questions before anything runs.
- open_form — Use this the moment the user wants to run this agent on their own input. It opens an interactive form that collects the run arguments. Do NOT check credentials, do NOT ask clarifying questions in chat, and do NOT run any analysis before calling this — the form is the entry point for running the agent.
- run_form — Internal: invoked by the open_form form when the user submits. Reads exactly the same arguments as run_full and forwards all of them. Not for direct use.
