Delimit Obs Impl
_delimit_obs_implFetch metrics, search logs, view health status, or manage alert rules from a single observability endpoint. Choose the action by name to read data or configure thresholds in one request.
Instructions
Unified observability entry point — dispatches to one of four actions.
When to use: as the single MCP-registered observability surface (delimit_obs) when the caller wants to pick the action by name in one call rather than choosing a specific delimit_obs_* alias. Covers runtime metrics, log search, alert-rule management, and the at-a-glance health rollup. When NOT to use: from internal code paths — prefer the specific alias (delimit_obs_metrics, delimit_obs_logs, delimit_obs_alerts, delimit_obs_status) for clarity and so docstrings and license gates show up at the right call site. For the governance-kernel layer use delimit_gov_health, not this runtime-observability surface.
Sibling contrast: each delimit_obs_ wrapper below is a thin alias over this implementation; they exist so the action's docstring lives at the right name. This is the dispatch core. Within the actions: "metrics" returns numeric series, "logs" returns text matches over the same backend, "status" returns a synthesised health rollup, and "alerts" configures thresholds against the metric series rather than querying data.
Side effects: action="metrics" / "logs" / "status" are READ-ONLY
and gated by require_premium (keys "obs_metrics", "obs_logs",
"obs_status") — unlicensed callers receive a license payload and no
backend call is made; licensed calls route to a distinct
observability backend function and are wrapped via _with_next_steps
for orchestrator hints. action="alerts" is the only WRITE-capable
path: its sub-action ("create" / "update" / "delete") mutates alert
configuration while "list" is read-only; it routes through the ops
bridge and is EXPERIMENTAL — the alert_rule schema is backend-
specific and may evolve. None of the read actions write data, append
to the ledger, or send notifications. Errors are deterministic
({"error": ...}): an unknown action short-circuits before any
backend call with the valid-action list.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Metric query name (action="metrics") or log search string (action="logs"). Default "system". For "logs" this is effectively required — empty searches are rejected by the backend. Ignored for "alerts" and "status". | system |
| action | No | Which observability operation to perform. One of "metrics", "logs", "alerts", "status". Default "status". Case-insensitive and whitespace-trimmed. Other values return a deterministic error listing the valid actions. | status |
| source | No | Optional data/log source override (used only when action="metrics" or action="logs"). Default None = backend default / all configured sources. | |
| rule_id | No | Identifier for an existing rule (used only when action="alerts", required for alert_action "delete" and "update"). | |
| alert_rule | No | Alert rule definition dict (used only when action="alerts", required for alert_action "create" and "update"). Backend-specific schema — typically metric, threshold, comparison, window, severity. | |
| time_range | No | Window like "1h", "24h", "7d" (used only when action="metrics" or action="logs"). Default "1h". Larger windows may downsample or be capped server-side. Ignored for "alerts" and "status". | 1h |
| alert_action | No | Alert sub-action — one of "list", "create", "update", "delete" (used only when action="alerts"). Default "list". "create"/"update"/"delete" write; "list" reads. | list |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||