Oracle connects AI assistants to cloud logs and traces for troubleshooting
The OCI Observability MCP Server combines investigation tools with reusable playbooks. Access follows the server’s configured identity, and guarded changes require confirmation.
The launch makes OCI logs and traces queryable through compatible AI clients, while authority remains tied to the server’s configured OCI identity and tools. In Oracle’s Codex demo, payment-error records fell from 175 to 162 across consecutive hours, but all still pointed to an invalid token affecting the gold loyalty segment; those counts did not establish unique affected requests, payment attempts, or failure rate. Optional read-only mode blocks resource changes, while change actions require confirmation and are audited.
01
The server can discover log sources, check ingestion, run queries, and connect events by host, request ID, or trace ID.
02
Oracle’s demo traced a rejected payment token to a checkout failure and an HTTP 422 response at the frontend, using APM Signals in Log Analytics.
03
Teams can tailor reusable investigation skills to application-specific failure patterns, including Kubernetes incidents, network reviews, and slow transactions.
Oracleintroduced the OCI Observability MCP Server on October 26, giving compatible AI assistants a way to investigate cloud application errors using logs and traces. Teams can ask questions in ordinary language, follow related events across services and produce evidence-backed reports, with controls that can keep investigations read-only.
From a question to cloud evidence
The connection uses Model Context Protocol, or MCP, an open standard for linking AI applications to external tools and data. Oracle says the server works with compatible command-line assistants, coding assistants inside development environments and DevOps agents. It bridges those clients to supported Oracle Cloud Infrastructure observability capabilities—the records and tools used to understand application behavior.
The tool set covers an investigation from discovery to follow-up. An assistant can find available log sources and fields, check whether logs are arriving, run queries and connect events through a host, request ID or trace ID. It can also turn results into charts and incident reports. For Log Analytics results, users can request the underlying query and continue examining it in Log Explorer.
Reusable troubleshooting skills supply the investigation method. Oracle describes a skill as a playbook specifying which sources to examine, which checks to perform, how to connect evidence and what findings to include. Teams can adapt these playbooks to their applications and known failure patterns. Examples include:
Kubernetes incident investigation: examine application issues and propose fixes for human approval.
Network flow security review: inspect logs for suspicious traffic, rejected connections and exposed endpoints.
Slow transaction investigation: examine records of transaction steps, known as spans, alongside related logs to investigate delays.
A payment failure followed across services
Oracle demonstrated the workflow with Codex and an e-commerce demo application running on OCI. A first prompt asked it to investigate payment failures and compare two consecutive one-hour periods. Codex found 162 matching payment-error records, down from 175 in the preceding hour. All matching errors in both periods referenced an invalid token and the gold loyalty segment: fewer records, but a continuing error pattern.
A follow-up prompt traced an affected request across the frontend, checkout and payment services using a shared trace ID. The evidence linked a rejected payment token to a checkout failure and an HTTP 422 response to the frontend. In this demonstration, the trace evidence came from APM Signals ingested into Log Analytics alongside application logs.
The final summary still identified work for investigators. Recommended checks included inspecting the demo’s payment-failure configuration and reviewing token validation if fault injection was disabled. It also recommended counting unique affected requests and total payment attempts to establish impact and failure rate. The error-record comparison alone did not supply those measures.
Investigation access is not permission to change resources
Access follows the permissions assigned to the server’s configured OCI identity. Available data and actions therefore depend on both those permissions and the enabled tools. Oracle’s guardrails also include an optional read-only mode, which allows queries and analysis while blocking changes to OCI resources.
Saving searches, creating dashboards and configuring alerts sit on the change side of that boundary. These guarded actions require a separate confirmation step so users can review a proposed operation before execution. Tool activity is recorded in an audit trail covering requested operations and their outcomes.
For setup, Oracle directs users to the project repository for configuration instructions and available tools. Its suggested starting point is a familiar application and a focused question, followed by inspection of the assistant’s supporting evidence before capturing results for review or reuse.
Sources
blogs.oracle.comIntroducing the OCI Observability MCP Server: Investigate Logs and Traces with Your AI Assistant
Reader comments
Newest comments first. Replies stay oldest first.