# Lambda observability for AI coding agents

Ivy is built so that coding agents such as Claude Code, Cursor and Codex can debug production Lambda functions on their own. An agent sets Ivy up from one prompt through `llms.txt`, then reads traces, errors and payloads through a **remote MCP server** or the **HTTP API**, and shows traces as interactive views right in the chat.

## Set up from one prompt

```
Set up Ivy for my AWS Lambda functions using https://ivytrace.dev/llms.txt
```

The prompt points the agent at [llms.txt](https://ivytrace.dev/llms.txt), a setup script written for agents. The agent signs you up with an OAuth device flow (you approve in your browser, and never hand it a password or AWS key), creates a workspace and project, gives you a CloudFormation link to connect your AWS account, previews which functions a rule would trace, and invokes one function to check that its trace arrived. At the end it offers to add the Ivy skill, an `AGENTS.md` pointer and the MCP server to your repo. It commits nothing without asking. See [agent setup](https://ivytrace.dev/docs/agent-setup).

## The MCP server

A remote MCP server at `https://ivytrace.dev/mcp`, with OAuth sign-in. It covers **all of your workspaces** at once, and every result says which workspace and project it came from.

| Tool | What it does |
|---|---|
| `list_workspaces` | The workspaces and projects you can read |
| `find_failing_invocations` | Recent failures for a function, grouped by error |
| `search_invocations` | Invocations by function, status, request ID, path or error message |
| `list_error_groups` | Errors by fingerprint, with counts and first and last seen |
| `get_trace_summary` | A whole trace as a compact text tree with timings, errors and trimmed payloads |
| `compare_invocations` | What differs between a good and a bad run |
| `render_waterfall` | The trace's waterfall as an interactive view in the chat |
| `render_graph` | The trace's service graph as an interactive view in the chat |

The tools are read-only and answer in compact text, so they spend few tokens. `render_waterfall` and `render_graph` are **MCP Apps**: hosts that support them show the real dashboard components inline, and other hosts get the text version.

Add it to Claude Code with:

```
claude mcp add --transport http ivy https://ivytrace.dev/mcp
```

Setup for Claude, Cursor and other clients: [MCP server docs](https://ivytrace.dev/docs/mcp).

## The HTTP API

Everything the dashboard does goes through an open HTTP API, described by an OpenAPI 3.1 document at [/api/openapi.json](https://ivytrace.dev/api/openapi.json) and browsable at [/api/docs](https://ivytrace.dev/api/docs). Any trace is available as text with `?format=text`:

```
GET https://ivytrace.dev/api/w/<workspace>/p/<project>/traces/<trace_id>?format=text
```

There is no Ivy CLI on purpose: agents already speak MCP and HTTP.

## The agent skill

The [Ivy skill](https://ivytrace.dev/skills/ivy/SKILL.md) is a `SKILL.md` file for your repo. It tells your agent when to reach for Ivy (a Lambda error, a slow endpoint, checking a deploy), which tools to call in which order, and which workspace and project belong to this repo.

## A typical session

> Checkout is returning 500s since this morning's deploy. Can you check Ivy?

The agent calls `find_failing_invocations` for the checkout function, opens one trace with `get_trace_summary`, sees that `SQS.SendMessage` to `order-events.fifo` fails with `MissingParameter: MessageGroupId`, finds the line in your code that dropped it, and fixes it. With MCP Apps, it shows you the waterfall in the chat while it explains.

## Why this matters

Your agent already has the code. What it usually lacks is production: the failing request, the payload that caused it, the stack trace, and what the function called. Ivy gives it that, scoped by the same sign-in and permissions you have.

---

Source: https://ivytrace.dev/features/ai-agents · Updated 2026-11-14