How do I ask the Codex CLI to investigate failed deploys with Tares?

Tares lets you ask the Codex CLI about failed deploys once Codex is connected to the Tares MCP endpoint. Codex calls the read tool and answers from one correlated timeline of deploys, logs, metrics and alerts. You add the endpoint with one codex mcp add command, then ask what happened to a service in the last 15 minutes.

How it works

Tares serves its tools over MCP. When Codex connects, it discovers them and uses them to answer your questions.

• The read tool returns a time-ordered timeline across all sources that match a label selector, such as the service label set to your service name.
• Metrics, logs, alerts and deploy events that carry the same service label land on one clock, so a deploy and the errors after it sit side by side.
• Findings that agents have recorded for that service are part of the timeline. Codex starts from the earlier conclusion instead of from scratch.
• Deploy events appear only if you send them. A webhook source fed by your CD pipeline puts each deploy on the service’s timeline.

This is the pull side. You ask when you want an answer, and Codex reads the evidence on demand. The Connecting agents (MCP) page covers every client and the full tool list.

Set it up

1. Start Tares and its MCP endpoint. Run tares up in one terminal and tares mcp in a second one. The local endpoint is http://localhost:8788/mcp.

tares up
tares mcp

On your own server the endpoint is your domain with /mcp at the end. On Tares Cloud the console shows it under Connect, with the exact command filled in. Nothing extra needs starting on either.

2. Add Tares to Codex. Keep --url before the URL, because a bare URL registers a stdio server.

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

3. On a secured instance, give Codex a read-scoped API key through an environment variable.

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

An open local instance needs no credential.

4. Verify the connection. Ask Codex: “Use tares: what are you ingesting right now?” It calls catalog_list and answers with your sources, triggers and projects. In the console, Reads lists each read as it happens, tagged client = mcp.

5. Make deploys visible. Create a webhook source with a primary service label read from the payload, the event type deploy, and a text template such as deploy {commit} by {author}: {message}. Creating it gives you a stable ingest URL. Add one line to your CD pipeline so every deploy posts to it.

curl -X POST https://<your-tares>/ingest/<ingest_key> \
  -H 'content-type: application/json' \
  -d '{"service": "checkout", "commit": "9f2c81d", "author": "dana", "message": "raise db pool size"}'

6. Ask about the failed deploy. Name the service and the window:

Use tares: what happened to checkout in the last 15 minutes?

Codex calls read with the service label set to checkout and answers from the correlated timeline. It can point to the deploy event, the first error or alert after it, and any earlier finding.

What you get

• One question replaces a tour of your deploy tool, log viewer and metrics dashboard. Codex reads logs, metrics, alerts, deploys and findings in a single call.
• The answer follows the timeline, so a sequence such as a deploy landing and errors starting two minutes later is visible in order.
• Every read shows up in the console under Reads, so you can check what Codex looked at.
• The same connection works for follow-ups. Codex can use catalog_describe to inspect a source, or read with sources to look at just the ones that matter.
• If you want Codex to leave a note for the next investigation, it can write a finding with record_finding on a project, or an observation with remember. Those writes need a key with the matching scope.

When something else fits

• If you want an agent woken the moment a service misbehaves, use the push side: a trigger fires and wakes an agent with the timeline already attached. The Build an AI SRE guide walks through it end to end.
• If you would rather not wire up an external client, the Ask chat in the Tares console uses the same read tools.
• Codex answers only from what Tares ingests. A service with no labeled deploy, log or metric sources has nothing to correlate yet.

Related