Skip to main content
Glama
delimit-ai

delimit

Official
by delimit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Delimit Obs Metrics

delimit_obs_metrics

Pull numeric metric series (CPU, memory, request/error rates, latency percentiles) for a time range to investigate runtime health and pair with log lines for anomaly correlation.

Instructions

Pull numeric metric series from the observability backend (Pro).

When to use: during runtime health investigation when you need numeric series (CPU, memory, request rate, error rate, latency percentiles) over a named time window. Pair with delimit_obs_logs to correlate a numeric anomaly with the underlying log lines. When NOT to use: for free-text search of log lines (use delimit_obs_logs), to read or configure alert rules (delimit_obs_alerts), or for a quick at-a-glance health rollup (delimit_obs_status).

Sibling contrast: delimit_obs_logs returns text matches; this returns numeric time series. delimit_obs_status is the rollup-summary surface; this is the raw-series surface. delimit_obs_alerts configures thresholds against these same series.

Side effects: read-only on the metrics 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_metrics which queries the backing metrics store; no data is written, no ledger entry, no notification. The response is routed through _with_next_steps.

Prerequisite: requires Delimit Pro. An unlicensed call returns {"error": ..., "upgrade": "https://delimit.ai/pricing"} without running.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoMetric query name. Default "system" (general system metrics). Backend-specific values supported.system
sourceNoOptional data source override. Default None = backend default source.
time_rangeNoWindow like "1h", "24h", "7d". Default "1h".1h

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv4.7.9
    • addedInput schema / properties / query / description
      Added value: +"Metric query name. Default \"system\" (general system metrics). Backend-specific values supported."
    • addedInput schema / properties / source / description
      Added value: +"Optional data source override. Default None = backend default source."
    • addedInput schema / properties / time_range / description
      Added value: +"Window like \"1h\", \"24h\", \"7d\". Default \"1h\"."
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior1/5

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

The description discloses rich behavior (read-only side effects, license gating with require_premium, internal call path, no ledger/notification effects), but it contradicts the annotation readOnlyHint=false by repeatedly asserting the operation is read-only and writes no data. Per the rubric, a description that contradicts annotations scores 1 and must be flagged.

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?

The key purpose is front-loaded in the first sentence, and the rest is organized under clear labels (When to use, When NOT to use, Sibling contrast, Side effects, Prerequisite). Dense but every section earns its place for a tool with license-gating and sibling ambiguity.

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?

For a tool with an output schema, 100% parameter coverage, and a complex licensing path, the description covers prerequisites, side effects, and sibling routing completely. The only issue is the annotation contradiction, which is scored separately; as prose, the contextual guidance is complete.

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 the schema already documents query, source, and time_range with defaults. The description's phrase 'named time window' aligns with time_range but adds no new parameter-level meaning; baseline 3 is appropriate.

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?

Opens with a specific verb and resource: 'Pull numeric metric series from the observability backend (Pro).' It names example metrics (CPU, memory, request rate) and contrasts with delimit_obs_logs (text vs numeric), delimit_obs_status (rollup vs raw), and delimit_obs_alerts (threshold config), so an agent can distinguish it from siblings without opening schemas.

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?

Provides explicit when-to-use guidance ('during runtime health investigation when you need numeric series'), a pairing strategy with delimit_obs_logs, and clear when-NOT-to-use exclusions that name the correct alternative for each excluded case. No inference is required.

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

Deploy Server

Other Tools