Signals and severity

A signal is a typed, evidence-backed statement that a monitored dependency changed.

Signal families

Family	Representative signal types
API contracts	`api_change`, `webhook_change`, `auth_config_change`
MCP	`mcp_tool_added`, `mcp_tool_removed`, `mcp_schema_breaking_change`, `mcp_auth_changed`
SDK and frameworks	`sdk_release`, `sdk_metadata_change`, `framework_change`, `adapter_change`, `cli_change`
Documentation and policy	`docs_deprecation`, `scheduled_change`, `predicted_change`
Commercial and operational	`pricing_change`, `rate_limit_changed`, `provider_status_change`
Behavior checks	`tool_behavior_drift`

Severity

Severity	Use
`breaking`	A previously correct client or agent will now fail
`high`	A behavior, cost, or operational change requires action
`medium`	Action is likely needed but not immediately blocking
`low`	Useful awareness with limited expected impact
`info`	Informational change

The structured_delta field carries type-specific mechanical details. The summary is for humans; automation should prefer stable fields such as signal_type, severity, evidence_ids, and identifiers.

Use breaking_only=true for release gates. Use min_severity for feeds and triage views that should still show non-breaking operational changes.

Getting started

Core concepts

Guides

Integrations

Signals and severity

Signal families

Severity

​Signal families

​Severity

Signal families

Severity