Lucid Observability Agent
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SENTRY_ORG | No | Sentry org slug (overrides config default) | |
| DATABASE_URL | No | PostgreSQL connection string for OpenMeter outbox (required for metering tools) | |
| AGENT_CONFIG_PATH | No | Path to custom config JSON | |
| SENTRY_AUTH_TOKEN | Yes | Sentry internal integration token (scopes: org:read, project:read, event:read, event:write) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| sentry_list_issuesC | List recent Sentry issues for a project. Supports Sentry search syntax. |
| sentry_get_issueB | Get full Sentry issue detail with latest event stack trace, tags, contexts, and cross-links. |
| sentry_get_issue_eventsC | Get recent events for a Sentry issue. Detects temporal patterns (burst, steady, regression). |
| sentry_resolve_issueC | Update a Sentry issue status: resolve, ignore, or unresolve. |
| sentry_search_by_traceB | Find all Sentry errors linked to a specific OTel trace ID across projects. |
| sentry_project_statsC | Get error rate trends for a Sentry project over a time range. |
| diagnose_issueB | Deep root-cause analysis of a Sentry issue. Examines stack trace, error patterns, frequency, and platform-specific knowledge to produce actionable diagnosis. |
| cross_correlateA | Correlate errors across services using trace_id or run_id. Finds related Sentry issues across all projects to build a cross-service error timeline. |
| openmeter_outbox_healthB | Check OpenMeter outbox queue health: pending events, dead letters, stuck leases, throughput. |
| openmeter_usage_by_orgC | Per-org usage breakdown: tokens, tool calls, costs by provider and model. |
| openmeter_dead_letter_retryA | Retry dead-letter events that have failed max attempts. Resets attempt count so the outbox worker picks them up again. |
| openmeter_usage_anomalyB | Detect usage anomalies: sudden spikes or drops in token usage per org compared to rolling average. |
| check_config_healthB | Audit observability configuration for production readiness. Checks Sentry, OTel, metering, PII, and environment settings. |
| check_conventionsC | Verify a service uses standard observability conventions: canonical names, required spans, attribute keys. |
| suggest_alert_rulesC | Generate Sentry alert rule configurations for a project based on error patterns. |
| generate_runbookB | Generate an incident runbook for a specific error category with triage, diagnosis, mitigation, resolution, and postmortem steps. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| triage-issue | Guided workflow to triage a Sentry issue: fetch details, diagnose, check cross-service impact, suggest fixes. |
| production-readiness | Full production readiness audit: config, conventions, metering, alerts. |
| incident-response | Guided incident response workflow. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| conventions | Observability conventions: service names, span names, attribute keys, and rules |
| services | Service topology and dependencies |
| sampling | Sampling strategy reference |
TDQS
Scored across 16 tools
Most tools have distinct resource+action targets (list/get/resolve issues, stats, health checks), but sentry_search_by_trace and cross_correlate both pivot on trace_id to find related errors and could be confused, and check_conventions vs check_config_health overlap somewhat on observability auditing.
All names are snake_case and mostly verb_noun, which is readable, but the convention is inconsistent: some tools carry service prefixes (sentry_, openmeter_) while others (check_conventions, diagnose_issue, cross_correlate, generate_runbook) do not.
16 tools is slightly heavy but justified given three distinct domains (Sentry, OpenMeter, config/observability auditing) that each need several operations.
Covers Sentry issue lifecycle (list, get, events, resolve), trace search, stats, correlation, runbook/alert generation, plus OpenMeter health/usage/retry and config auditing; minor gaps like issue commenting or alert rule mutation, but core observability workflows are covered.