How do I ask the Codex CLI to investigate high latency with Tares?

Tares lets the Codex CLI investigate high latency once you connect it over MCP and ask what happened to the slow service in the last 15 minutes. Codex answers from one correlated timeline of metrics, logs, alerts and findings, read through the Tares read tool. Setup is one codex mcp add command pointed at your Tares MCP endpoint.

How it works

Tares ingests your metrics, logs and alerts as sources that share a label such as service. Because they share it, they merge into one time-ordered timeline per service. The Tares MCP server exposes that timeline to any MCP client, including Codex.

When you ask Codex about a service, it discovers the Tares tools and calls read with a label selector such as {"service": "api-server"}. It gets back the correlated timeline: the latency metric, the request logs, any fired alerts and any earlier findings, all on one clock. Codex reasons over that single read instead of querying each system separately.

The MCP endpoint depends on where Tares runs:

• On your machine, http://localhost:8788/mcp. The daemon alone does not serve /mcp, so you start the MCP server as a second process.
• On your own server, https://your-domain/mcp.
• On Tares Cloud, the endpoint shown under Connect in your console. Each instance has its own hostname.

On a server or Tares Cloud instance the MCP server is already running, so there is nothing to start.

This is the pull side of an AI SRE: you or an agent you already use investigates on demand. The push side, where a trigger wakes an agent, is covered in the same guide.

Set it up

1. Start Tares locally and keep it running.

   tares up

2. In a second terminal, start the MCP endpoint. It listens on http://127.0.0.1:8788/mcp.

   tares mcp

3. Register the endpoint 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 you connect to a secured server or a Tares Cloud instance, replace the URL with yours and let Codex read an API key from an environment variable. Prefer a scoped API key with the read scope over the root token. The console’s Connect page generates these commands with the endpoint and token filled in.

   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 should call catalog_list and answer with your sources, triggers and projects.

6. Ask about the latency problem:

   Use tares: what happened to api-server in the last 15 minutes?

   Swap api-server for your own service name. Codex calls read with that service label and answers from the correlated timeline.

Want to see a latency incident without touching production? The AI SRE guide stands up a demo system with a HighLatency alerting rule and a latency scenario you can trigger. Ask Codex the same question before and after, and the second answer shows the alert and the metric that tripped it. Per-client setup for Claude Code, Cursor and other MCP clients is on the Connecting agents page.

What you get

• One answer built from the whole picture. Latency metrics, request logs, alerts and findings arrive merged on one clock, so Codex can tie a spike to specific evidence lines.
• A starting point that improves over time. If a Tares agent or another outside agent has already written a finding for the service, read includes it, so Codex starts from the previous conclusion instead of from scratch.
• Visibility into what Codex asked. In the console, Reads lists each read as it happens, tagged client = mcp.
• More than read access when you want it. The same connection exposes create_trigger so Codex can set up a trigger to be woken when the problem happens again, and remember to write back what it found. A key’s scope decides which of these succeed, so a read key keeps Codex to the read surface.
• A narrower scope for a focused agent. A project key lets an agent work inside one project only: it reads that project and records findings in it, and nothing else.

When something else fits

• If you want an agent woken the moment latency crosses a threshold, use a trigger, which is the push side of the AI SRE guide, instead of asking by hand.
• If you would rather not wire up an external client, the console includes an in-app agent under Ask that uses the same read tools.
• If your client supports only stdio servers, use the stdio transport with tares-mcp installed where the agent runs, as described on the Connecting agents page.

Related