How do I ask the Cursor agent to investigate failed deploys with Tares?

Tares lets the Cursor agent investigate failed deploys once you connect it over MCP and ask what happened to a service in the last 15 minutes. Cursor calls the read tool and answers from one correlated timeline of logs, metrics, alerts and findings. If deploy events are on that timeline, the agent can see a deploy land and the errors that followed it.

How it works

Tares does the data side and Cursor is the agent that reads it. Cursor connects to the Tares MCP endpoint and discovers the Tares tools.

• read returns a time-ordered timeline across all sources that match a label selector, such as a service label set to the service you name.
• catalog_list and catalog_describe show what Tares is ingesting and how each source is shaped.
• list_findings and record_finding let the agent read earlier conclusions and write its own, so the next investigation starts from the last one.

When you ask “what happened to api-server in the last 15 minutes?”, Cursor calls read for that service and answers from the merged evidence. The agent sees the same read an in-Tares agent works from. For the full pull and push picture, see Build an AI SRE.

Set it up

1. Start Tares on your machine and leave it running.

   tares up

2. In a second terminal, start the MCP server. The daemon alone does not serve /mcp, so this step is needed locally. On your own server or on Tares Cloud the MCP server is already running and there is nothing to start.

   tares mcp --transport streamable-http

3. Add Tares to ~/.cursor/mcp.json (global) or .cursor/mcp.json (per project), then approve the server under Settings → MCP.

   {
     "mcpServers": {
       "tares": {
         "url": "http://localhost:8788/mcp"
       }
     }
   }

   For your own server the URL is your domain followed by /mcp. On Tares Cloud, copy the endpoint from the Connect page in your console. That page also fills in the exact command and token for your client.

4. If the instance is secured, the MCP surface needs a credential. Use a scoped API key with the read scope rather than the root token. For an agent that should work in one project only, use a project key.

5. Verify the connection. Ask Cursor:

   Use tares: what are you ingesting right now?

   Cursor should call catalog_list and list your sources, triggers and projects. In the console, Reads shows each read as it happens, tagged client = mcp.

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

   Use tares: what happened to api-server in the last 15 minutes? Did a deploy land before the errors started?

7. Put deploys on the timeline. Create a webhook source with a primary service label and event_type set to deploy. Add a text template such as deploy {commit} by {author}: {message}. Have your CD pipeline POST to its ingest URL on every deploy. Each POST lands as a deploy event on that service’s timeline, next to the logs, metrics and alerts that carry the same service label.

What you get

• Cursor answers from a single correlated timeline instead of one query per system.
• A deploy event sits on the same clock as the errors, so the agent can say “deploy landed 14:02, errors started 14:04”.
• Earlier findings are part of the read, so a repeat investigation starts from the previous conclusion.
• The agent can write back with record_finding, so what it learns stays on the timeline for the next person or agent.
• You can follow each question in the console under Reads.

The Connecting agents page covers per-client setup for the other MCP clients, so the same questions work from any of them.

When something else fits

• If you want an agent woken the moment something breaks, instead of asking it yourself, add a trigger. Tares can wake a Tares agent or POST the timeline to your own agent service. Build an AI SRE walks through both.
• If you would rather not wire up an external client, use Ask in the Tares console. It runs the same read tools inside Tares.

Related