For AI agents
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, 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.
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/mcpSetup for Claude, Cursor and other clients: MCP server docs.
The HTTP API
Everything the dashboard does goes through an open HTTP API, described by an OpenAPI 3.1 document at /api/openapi.json and browsable at /api/docs. Any trace is available as text with ?format=text:
GET https://ivytrace.dev/api/w/<workspace>/p/<project>/traces/<trace_id>?format=textThere is no Ivy CLI on purpose: agents already speak MCP and HTTP.
The agent skill
The Ivy skill 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.