Observability CLI Guides

Observability CLI Guides

One reference file per stack, carrying everything the package knows about it: the query CLI and how to set it up, the discovery-then-query commands per signal, how its configuration is displayed and proven, and what its stack_config persists. Pick the observed stack's reference, then follow the linked official docs — the fetched page is the source of truth, not memory. The method is the same everywhere: authenticate, discover what the service emits, then query what you discovered.

Pick the backend

The list of built-in stacks — every value the MCP server's STACKS accepts, with its reference, CLI, and aliases — is references/builtin-stacks.md; it is what backend-configuration (its ## Check and ## Switch) and /odd-config read. The query surface per backend:

Authoring a reference, or a custom stack file: every reference follows references/CONTRACT.md — the sections it must carry, what each answers, and who reads it. A mission never opens it.

For the local oddyssey stack (the Grafana case), the setup-local-stack skill carries the ready-made gcx context — isolated config and datasource UIDs. gcx is the stack's mandatory query CLI.

For Grafana — remote or local — the query commands are the scripts under scripts/grafana-*.py; grafana.md's ## Query by signal is the one place that states them, with every flag.

Rules

• Recommendations and commands must come from the reference's linked docs, fetched — never from memory; CLIs move fast.
• Credentials come from the environment or the caller (env vars, secret stores); never invent, echo, or store them.
• Planning notes are a snapshot (last verified 2026-08); the fetched official page always overrides them.
• A reference talks about its own backend only — never a comparison with another backend's product (routing to the local stack is not one).
• If the stack's backend is not in the table, say so and fall back to the backend's documented REST API over curl — the discover-then-query method still applies.