How do I ask the Codex CLI to investigate a disk filling up with Tares?

Tares lets the Codex CLI investigate a disk filling up once you connect Codex over MCP and ask what happened to the affected service in the last 15 minutes. Codex calls the read tool and answers from one correlated, time-ordered timeline of logs, metrics, alerts and findings. You get the evidence for the service in a single read instead of querying each system by hand.

How it works

This is the pull side of Tares: you ask, and the agent reads.

• Tares ingests your sources and keys them by a shared label, such as service. Sources that carry the same label merge into one timeline per service.
• The MCP endpoint exposes Tares tools to Codex. The main one is read, which returns a correlated timeline across all sources that match a label and value selector.
• When you ask about a service, Codex calls read with that service label. The timeline puts logs, metrics, alerts and findings on one clock, so a growing disk metric, the log lines around it and any alert that fired sit side by side.
• Findings that earlier investigations or Tares agents recorded appear in the same read, so Codex starts from the previous conclusion instead of from scratch.

The local MCP endpoint is http://localhost:8788/mcp. On your own server it is https://<your-domain>/mcp, and on Tares Cloud the console shows it under Connect. For the full build of the pull and push halves, see Build an AI SRE.

Set it up

1. Start Tares locally.

   tares up

2. In a second terminal, start the MCP endpoint. The daemon alone does not serve /mcp.

   tares mcp

3. Register Tares with Codex. Keep --url before the URL, because a bare URL registers a stdio server.

   codex mcp add tares --url http://localhost:8788/mcp

4. If your instance is secured, such as a server or Tares Cloud, Codex reads the credential from an environment variable. Use an API key with the read scope.

   export TARES_API_KEY=<api-key>
   codex mcp add tares --url https://<your-host>/mcp \
     --bearer-token-env-var TARES_API_KEY

5. Verify the connection. Ask Codex:

   Use tares: what are you ingesting right now?

   Codex calls catalog_list and answers with your sources, triggers and projects. If your disk metrics are not on that list, add them as a source first. A source such as Prometheus works when it carries the same service label as your logs.

6. Ask about the incident. Replace api-server with the name of the service whose disk is filling:

   Use tares: what happened to api-server in the last 15 minutes? Is anything about its disk growing?

   Codex calls read for that service and answers from the correlated timeline. In the console, Reads lists each read as it happens, tagged client = mcp.

The connecting agents page has the per-client commands for other tools and the details on authentication.

What you get

• One answer from one read. Codex sees the metric, the logs and any fired alert for the service on the same clock, so it can tie the disk growth to specific evidence lines.
• A visible trail. Every read shows up in the console under Reads, tagged as coming from MCP.
• Continuity. Findings recorded in earlier investigations come back in the timeline, so the next question starts from what was already concluded.
• Follow-ups in the same session. Codex can use catalog_describe to look at one source’s schema and freshness, or read with sources to narrow the timeline to just the sources that matter.
• A path to automation. Once the question is one you ask often, a trigger can wake an agent for you, as described in Build an AI SRE.

When something else fits

• If you want to be woken when a disk fills rather than ask after the fact, create a trigger so Tares wakes an agent with the timeline, as the AI SRE guide shows.
• If you would rather not wire up an external client, the Ask chat in the Tares console uses the same read tools inside Tares.
• If you work in Claude Code, Cursor or another MCP client, the connect step differs but the question and the answer are the same.

Related