AgentKit

Detect Kpi Anomalies

detect_kpi_anomalies

Detect statistical anomalies and sudden spikes in KPI time-series history using Z-Score or IQR methods to flag operational risks and budget variances across business domains.

Instructions

Detect statistical anomalies, sudden spikes, and unexpected deviations in KPI time-series history.

Analyzes metric historical distributions within a specified business domain using rigorous parametric (Z-Score) or non-parametric (IQR - Interquartile Range) anomaly detection algorithms to identify operational risks, unexpected budget variances, or sudden performance degradation.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes	Target business domain to evaluate (e.g. 'Finance', 'Operations', 'Customer', 'People', 'Engineering', 'Growth', 'ESG', 'IT'). Required.
`method`	No	Statistical anomaly detection algorithm to execute. Options: - 'zscore': Standard deviation testing for normally distributed metrics (default). - 'iqr': Robust quartile range testing for skewed or fat-tailed metric distributions.	zscore
`threshold`	No	Sensitivity cutoff factor for classification. For 'zscore', specifies standard deviations from mean (default: 2.5). For 'iqr', specifies multiplier above Q3/below Q1 (default: 1.5).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.16Sep 27, 2026

addedInput schema / properties / domain / description

Added value: +"Target business domain to evaluate (e.g. 'Finance', 'Operations', 'Customer',\n'People', 'Engineering', 'Growth', 'ESG', 'IT'). Required."

addedInput schema / properties / method / description

Added value: +"Statistical anomaly detection algorithm to execute. Options:\n- 'zscore': Standard deviation testing for normally distributed metrics (default).\n- 'iqr': Robust quartile range testing for skewed or fat-tailed metric distributions."

addedInput schema / properties / threshold / description

Added value: +"Sensitivity cutoff factor for classification. For 'zscore', specifies standard\ndeviations from mean (default: 2.5). For 'iqr', specifies multiplier above Q3/below Q1 (default: 1.5)."

First observedv0.1.0Sep 26, 2026

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the analytical methods (parametric Z-Score vs non-parametric IQR) and their rationale, which is useful behavioral context, but does not state that this is a read-only analysis, nor mention data-freshness or volume constraints. Adequate but incomplete for an annotation-free tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action and followed by method context. Slightly diluted by qualifiers ('rigorous', 'operational risks, unexpected budget variances, or sudden performance degradation'), but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. For a three-parameter, single-required analysis tool the description covers purpose, methods, and domain scope adequately; only usage routing against siblings is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (domain, method, threshold) are already fully documented in the schema, including defaults and algorithm semantics. The description adds no parameter detail beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb (detect) plus resource (KPI anomalies/time-series deviations), scoped to a business domain. An agent can readily distinguish this from siblings like forecast_metric or query_kpis, which do not perform anomaly classification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the stated goal ('identify operational risks, unexpected budget variances'), but there is no explicit when-to-use guidance or contrast with alternatives such as forecast_metric or get_company_health. The agent must infer the trigger conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server