Skip to main content
Glama

delimit_obs_status

Return a health rollup from the observability layer, providing overall and per-service status for quick smoke tests or dashboard display.

Instructions

Return a high-level health rollup from the observability layer (Pro).

When to use: for the "are we green?" check at session start, in a status dashboard, or as a single-call smoke test before a deploy. The orchestrator's session-start ritual calls this only if delimit_agent_dashboard or delimit_gov_health flag anomalies — it is the second-tier health surface, not the first. When NOT to use: for detailed numeric series (delimit_obs_metrics), for log investigation (delimit_obs_logs), or for alerting rule management (delimit_obs_alerts). Also do not use as the only deploy gate — pair with delimit_security_audit + delimit_test_smoke per the deploy chain.

Sibling contrast: delimit_obs_metrics returns raw numeric series; this returns a synthesised rollup (typically per-service status + a few key indicators). Compared to delimit_gov_health, this reports the runtime observability layer rather than the governance kernel.

Side effects: read-only on the observability backend and gated by require_premium — unlicensed callers receive a license payload and no query runs. On a licensed call, invokes backends.tools_infra.obs_status which composes a health summary from the backing data sources. No write, no ledger entry, no notification. Response is wrapped through _with_next_steps.

Args: None.

Returns: Dict with keys: overall (green/yellow/red), services (list of {name, status, indicators}), checked_at timestamp, plus a next_steps field from _with_next_steps. Returns a license-gate payload if the caller lacks Premium, or {"error": "..."} on backend failure (does not raise).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description fully discloses read-only behavior, premium licensing gating, internal call chain (_with_next_steps, backends.tools_infra.obs_status), and response wrapping. States no writes, no ledger entry, no notifications.

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

Conciseness5/5

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

Though longer, the description is modularly structured: purpose, usage, contrast, side effects, returns. Each section is front-loaded with key information. No redundant sentences; every line adds diagnostic value.

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

Completeness5/5

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

The description fully covers return format (overall, services, checked_at, next_steps, error/ license payload), error handling, and licensing behavior. Given no input parameters and comprehensive output schema description, it is fully complete.

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

Parameters4/5

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

No parameters exist (schema coverage 100%), and the description explicitly says 'Args: None.' This adds clarity by confirming absence of inputs, preventing any assumption of hidden parameters. Baseline for 0 params is 4.

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?

The description starts with a precise verb+resource: 'Return a high-level health rollup from the observability layer (Pro).' It clearly differentiates from siblings like delimit_obs_metrics (raw series vs. synthesised rollup) and delimit_gov_health (runtime observability vs. governance kernel).

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

Usage Guidelines5/5

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

Explicit 'When to use' and 'When NOT to use' sections with concrete alternatives (delimit_obs_metrics, delimit_obs_logs, delimit_obs_alerts) and deploy chain pairing advice (delimit_security_audit + delimit_test_smoke). No ambiguity.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/delimit-ai/delimit-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server