Skip to main content

v1.0.141

Causality graph for agents​

Causely MCP tools now return the entity causality chain behind a diagnosis. Previously, agents received a diagnosis and its symptoms but had to piece together how the problem spread across entities. get_diagnosis_details and get_issue_details now return each affected entity, its distance from the root entity, and the symptoms, events, and SLOs the diagnosis causes there, so agents can explain why Causely reached a diagnosis from the causal model itself. In the portal, the Causality graph now hides workloads with no symptoms, which reduces noise for services with many replicas.

Causal graph produced by agent using Causely MCP

Detection of rejected requests on internet-facing services​

Causely now detects when a service rejects requests because of authentication failures (401, 403), rate limiting (429), or policy rejections (451). Previously, an API gateway or other internet-facing service could reject traffic and still look healthy, because its callers are not instrumented and most 4xx responses were counted as successful requests. These services now produce a diagnosis based on their own inbound traffic, even when every client is on the public internet.

Learn more

Issue-first navigation​

Issues are now the primary entry point for investigation, in the portal and for agents. Diagnosis is no longer in the side navigation and remains available at its existing URLs. The API and MCP tools now navigate from an alert or entity directly to its related Issues, so agents no longer need a separate lookup to find the Issue behind an alert.

Alert new resolve directly to the Issue

Minor Improvements​

  • Notification filters: Notifications can now filter on the number of degraded services, so you can notify only when an Issue affects more than a set number of services.
  • SLO tool: get_slo now reports the share of error budget remaining. Previously, it could report each objective's margin instead. is_violated and is_at_risk now follow SLO severity.
  • Service summary tool: get_service_summary accepts a cluster name, so agents can target the production service rather than a same-named service in staging. The status line is now derived from the same diagnoses, SLOs, and metrics shown in the summary, and name resolution errors are reduced.
  • MCP reliability: Filter tools return an explicit error when a cluster or namespace name matches nothing, instead of an empty result an agent could read as healthy. name_lookup matches namespace and cluster names more tolerantly, an unknown entity ID returns a not-found error, and OAuth for MCP connections is improved for enterprise agent platforms.
  • Logs and events in MCP: Error lines show at least the full first line, grouped by signature with a count and first and last seen times. Version changes name the from and to image or revision.
  • MCP prompts: The Causely MCP server now provides prompts that guide agents through common workflows, consistent with Causely skills.
  • Load balancer and endpoint topology: When an AWS ALB or NLB port maps to more than one service, Causely links traffic to the Service that owns the load balancer instead of skipping the link. GKE Ingress and internal passthrough load balancers resolve to the real backend service, and stale external services are dropped.
  • Access thresholds: Thresholds on access entities are now derived correctly from their HTTP path, and activation delay is no longer configurable on individual access entities.
  • Notifications from merged Issues: Cleared Issues no longer send stale notifications after being merged into another Issue.
  • GKE ARM nodes: The Causely agent now rolls out on GKE ARM nodes, which carry a default arm64 taint.
  • MCP Inspector: The MCP Inspector page no longer refreshes and resets responses during a session.