code0Vörr AIContactDocs
Book a Demo
← Back to blogDevOps

How Vörr Lets Claude and Codex Investigate Your Production Stack Through MCP

How Vörr Lets Claude and Codex Investigate Your Production Stack Through MCP


Claude can reason about a production incident. The problem is that production cannot answer back.

The evidence is scattered across cloud resources, metrics, logs, traces, deployments, and source code. Debugging with AI quickly becomes a copy-paste exercise between several tools.

Vörr changes the interface. It puts production context behind MCP so Claude and Codex can investigate connected systems instead of waiting for you to bring every piece of evidence into the chat.

1. One MCP Interface

WHAT IS MCP?

Model Context Protocol (MCP) gives an AI application a standard way to discover tools, call them, and retrieve external context.

Vörr works as an MCP server connected to the AI you already use. Claude or Codex remains responsible for understanding the question and reasoning over the result.

Vörr handles the other half:

  • authenticate the user
  • scope the request to the correct organisation
  • query connected engineering systems
  • return structured production facts

So a question like "Why did checkout latency increase after the last deploy?" does not need to begin with manually collecting screenshots, logs, and deployment history.

2. Org-Scoped Access

Giving an AI access to production needs a different security model from pasting data into a chat.

Authentication happens through OAuth, with requests scoped to the authenticated user and organisation. For Cloud Mapper queries, Vörr uses a short-lived, organisation-scoped internal token to access read-only investigation tools. This token is separate from the credentials used to connect the cloud account.

Claude / Codex → OAuth → Vörr → User + org scope → Read-only production data

The AI receives retrieved context through tools; cloud-account authentication is handled by the backend.

3. Infrastructure Graph

A list of cloud resources is useful. A graph of how those resources connect is much more useful during an incident.

Service

  |

  v

ECS / VM / Pod

  |

  v

Network

  |

  v

Security Group

  |

  v

Load Balancer / Public Traffic

The same graph can represent relationships around databases, storage, queues, repositories, and other infrastructure. A resource by itself is inventory. A resource with its relationships becomes context.

4. Composite Tools

Giving an AI hundreds of tiny infrastructure APIs creates another problem: the model has to know how deep to investigate.

Without a composite tool

AI

 |

getService()

 |

getNetwork()

 |

getENI()

 |

getSecurityGroup()

 |

getExposure()

The model chooses every hop.

With Vörr

AI

 |

inspect service exposure

 |

Vörr traverses relationships

 |

Evidence

The infrastructure-specific traversal happens underneath one meaningful question.

This reduces the chance of the agent stopping one layer too early and turning a partial lookup into a clean but incorrect answer.

5. Live Signals

The infrastructure graph explains how production is wired. Observability explains what production is doing right now.

Vörr exposes connected runtime systems as read-only tools so the agent can inspect errors, metrics, logs, traces, deployments, alerts, and health.

Latency spike

  |

  v

Affected service

  |

  v

Recent deploy

  |

  v

Trace / dependency

  |

  v

Related code change

Instead of receiving one dashboard at a time, the AI can correlate what changed with what became unhealthy.

6. Code + Production

Production debugging rarely ends at the infrastructure layer. An alert may identify the failing pod. A trace may identify the service. Eventually someone asks: "What changed in the code?"

Connected repositories are available through the same MCP layer. The AI can search code, locate symbols, inspect references, read files, understand dependencies, and inspect recent changes without introducing another reasoning model between the source and Claude or Codex.

Production error -> Service -> Deployment -> Repository -> Recent change -> Relevant code

Cloud and code become different parts of the same investigation.

7. Missing Data Is Not Zero

The most dangerous production answer is sometimes not a wrong value. It is a confident zero.

Empty resultWhat it actually means
Scanned and emptyThe scan completed and there genuinely are no matching resources.
Scan incompletePermissions, throttling, or another failure prevented a complete scan.
Out of scopeThat resource type is not currently indexed by the tool.

Vörr exposes coverage alongside the data rather than converting missing visibility into confident absence. The same principle applies to observability: "no errors found" means something very different when no error source is connected.

8. Production Investigation Through MCP

Cloud infrastructure

+ Metrics / Logs / Traces

+ Deployments

+ Repositories

        |

        v

       Vörr

        |

       MCP

        |

        v

 Claude / Codex

The AI remains the reasoning engine. Vörr gives it a read-only, organisation-scoped way to inspect the systems it is reasoning about.

Same AI. Same conversation. Production it can actually investigate.


Explore Vörr

Connect production context to the AI tools your engineering team already uses.

Explore Vörr →

Related in this series: How Vörr Cloud Mapping Connects Infrastructure, Services, and Repositories into One Debugging Context | Why AI Agents Get Infrastructure Wrong - And How Context Helps.

SU
Shivam Upadhyay · Frigga
More posts by Shivam →
Engineering insights from the Frigga team.
New posts twice a month. No spam, unsubscribe any time.