Arize Phoenix has a built-in MCP server that lets your agents query traces with SQL

Arize Phoenix now ships a built-in Model Context Protocol (MCP) server that lets coding agents query traces with SQL, reducing average cost by about 17x in an eight-question benchmark. The server provides two read-only SQL tools, describeSqlSchema and executeSql, and never runs the model's SQL as written, checking and bounding every statement. In one benchmark question, retrieval-only tools took 89 turns, about 14 minutes, and $10.35 in tokens, while SQL tools answered the same question at significantly lower cost.

TL;DR - Phoenix ships a built-in MCP server, so a coding agent https://arize.com/blog/open-source-coding-agent-tracing/ can now work with your traces https://arize.com/glossary/trace/ over MCP. - The server now has two read-only SQL tools, describeSqlSchema and executeSql , so an agent can query your traces instead of paging through them. - The agent uses them in code mode: it writes a short program, the program calls the tools inside a sandbox, and only the result reaches the model. - The server never runs the model’s SQL as written. Every statement is checked, rebuilt, and bounded before the database sees it. - Across an eight-question benchmark, the SQL tools answered the same questions at about 17x lower cost than retrieval-only tools. Phoenix https://arize.com/phoenix/ now ships with a built-in MCP Model Context Protocol https://arize.com/glossary/model-context-protocol-mcp/ server, so coding agents can inspect traces from the same environment where they write and debug code. For questions that require aggregation across many spans, retrieval-only tools can get expensive because the agent has to page data through model context. SQL changes the shape of the work: the database handles the filtering, joins, and aggregation, while code mode keeps intermediate results in a sandbox. In our eight-question benchmark, this approach reduced average cost by about 17x. Retrieval-only MCP: 89 turns for one count Here is what happened when we gave an agent one question and only the server’s retrieval tools. The question: “How many traces hit a high-impact error?” To answer it, the agent had to work through the spans, the individual model and tool calls that make up each trace. It listed the projects, found the right one, and fetched spans a page at a time. The project held more JSON than the agent could carry at once, so it read a page, tallied what it needed, fetched the next, and repeated. After 19 pages, it answered correctly: 99 traces. The run took 89 turns, about 14 minutes, and $10.35 in tokens. That gap is what this feature closes. The database held the answer the whole time; the shape of the tools is the only reason the agent paid so much to rebuild it. Why retrieval-only MCP tools gets expensive on agent traces Most MCP retrieval tools expose data as objects to fetch: list the projects, fetch a page of spans, read the annotations on a span. That shape is ideal when you want one specific thing like the full detail of a single trace. But it gets expensive when the question asks for a count, average, percentile, or breakdown across many traces because the agent must retrieve every relevant span and perform the aggregation itself. The only way to get one of those answers is to pull back every relevant span and do the arithmetic yourself. That arithmetic is especially expensive for LLM trace data. A typical infrastructure log line is short: a timestamp, a status code, a duration. An LLM span can carry the prompt and the completion, so a single row may hold kilobytes of text. That makes trace data one of the worst things to read page by page, and one of the best things to summarize before the model ever sees it. That is what happened in the opening example. The agent fetched all 3,624 spans, carried running totals across 19 pages of JSON, and rebuilt a number the database could have produced in one query. Every page had to pass through the model on the way in, and that is where the turns, the minutes, and the dollars went. Handed only objects to fetch, an agent behaves like a scraper. We wanted it to query like an analyst. How Arize Phoenix’s MCP server runs SQL through code mode So we gave the agent two tools for asking the database directly. Both live on Phoenix https://arize.com/docs/phoenix/ ‘s MCP server, and both are read-only. describeSqlSchema shows the agent the tables it can query and how they connect. executeSql runs one read-only SQL statement and returns the rows. With those two tools, the agent can look up the shape of your telemetry https://arize.com/blog/ai-agent-observability-why-production-systems-need-a-reasoning-layer/ and then ask a precise question, the way you would from a SQL console. Code mode is the piece that keeps this cheap. Instead of calling tools from the chat one at a time, the agent writes a short Python program. Phoenix runs that program server-side in a restricted Monty sandbox, and the program calls the MCP tools from there. The intermediate schema lookups and query results stay inside the sandbox; only the final value the program returns reaches the model. Phoenix enables code mode by default for the remote MCP server. Here is how the agent answered the same high-impact-error question against trail-gaia , the sample project used in the benchmark. The project holds the same 3,624 spans from the slow run. In this dataset, a high-impact error is a trail error annotation with a score of 1.0, so the query counts the distinct traces with at least one matching annotation. result = await call tool "executeSql", {"sql": """ SELECT COUNT DISTINCT t.id AS n FROM span annotations sa JOIN spans s ON s.id = sa.span rowid JOIN traces t ON t.id = s.trace rowid JOIN projects p ON p.id = t.project rowid WHERE p.name = 'trail-gaia' AND sa.name = 'trail error' AND sa.score = 1.0 """} return result "rows" 99 : the only value that reaches the model This time the run took 7 turns, about 33 seconds, and $0.23, compared with 89 turns, about 14 minutes, and $10.35 the first way. The answer was identical: 99 traces. The difference was that the 3,624 spans never left the database. Only the final count came back to the model. How Phoenix keeps agent-written SQL read only Agent-written SQL needs a strict boundary. Phoenix does not execute the model’s statement directly. It parses the query, restricts it to approved telemetry data, rebuilds it, applies database-level checks, and caps execution and result size. Parse it first. The server turns the SQL into a structured query, so the checks look at what the query does, not how the text happens to be written. Allow only permitted tables and columns. If the query asks for anything outside the approved telemetry surface, it is refused before it runs. Rebuild the statement. Phoenix generates fresh SQL from the parsed query. The database runs that rebuilt statement, not the model’s original text. Let the database enforce the boundary too. The rebuilt query still has to pass a SQLite authorizer or a Postgres query-plan check. Cap every query. Queries are read-only and bounded by runtime, row count, and result size. That is the core contract: read-only SQL, parsed rather than trusted, and bounded before it runs. The SQL tools do not create a new path into your data. They can only read telemetry the signed-in user can already access in Phoenix, and they cannot change anything in the database. Benchmark: SQL + code mode vs. retrieval-only tools We ran eight telemetry questions three times in two configurations of the same agent: retrieval tools only, and SQL tools running in code mode. The questions covered counts, percentiles, category breakdowns, joins, and trends over time. A scoring model graded every answer, and we manually reviewed the outputs. Across the benchmark, combining SQL and code mode averaged about $0.23 per question, compared with $3.97 for retrieval-only tools or about one-seventeenth the cost . The full picture, question by question: Question | SQL $ | Retrieval $ | Retrieval / SQL | SQL turns | Retrieval turns | |---|---|---|---|---|---| | High-impact error count | 0.23 | 10.35 | 44x | 7 | 89 | | p95 LLM-span duration | 0.22 | 4.96 | 23x | 6 | 49 | | 10-min time buckets | 0.28 | 4.76 | 17x | 6 | 100 | | Average span duration | 0.19 | 3.69 | 19x | 6 | 54 | | Five longest spans | 0.23 | 3.66 | 16x | 6 | 55 | | Breakdown by span kind | 0.18 | 1.90 | 10x | 6 | 89 | | Tool-related error count | 0.22 | 1.71 | 8x | 7 | 67 | | Average reliability score | 0.31 | 0.70 | 2x | 8 | 13 | Average | 0.23 | 3.97 | 17x | 6.5 | 64.5 | Cost is the obvious difference, but it is not the only one. Take the grouped breakdown of spans by kind. The SQL run answered with exact counts in 6 turns. In one of its three runs, the retrieval agent paged the whole project, searched the files it had saved, and reported 622 spans of kind TOOL. The real number is 626. That four-span error survived 103 turns and $2.01 of effort, and the scoring model still marked it correct. Counting by hand across a dozen pages is exactly where a small error like that slips in. There are two things the benchmark does not yet cover. The hardest multi-step correlations are not in this set yet. And on a trivial lookup, like the single filtered count in the last row, the retrieval tools can be cheaper because there is nothing for SQL to collapse. SQL pulls ahead whenever the alternative is reconstructing the answer by hand, and that is most of debugging. Connect your coding agent to Phoenix’s MCP server Phoenix’s built-in MCP server is available in Phoenix 19.0.0 and later, and the SQL tools are available in v20.2.0 and later. Connect Claude Code, Cursor, MCP Inspector, or another MCP client to your Phoenix endpoint and authorize over OAuth. The px CLI can write the config for you: px setup mcp --agent claude or codex, cursor, gemini, opencode, vscode You can also set it up by hand. In Claude Code, that is one command: claude mcp add --transport http phoenix https://your-phoenix-host/mcp For setup details across clients, see the Remote MCP Server https://arize.com/docs/phoenix/integrations/remote-mcp docs. Then ask the questions you already use to debug production traces https://arize.com/resources/agent-evals-from-traces/ : Which tools fail most often? Where is latency concentrated? How many traces hit an error this week? The agent can inspect the schema, write a read-only query, and return the answer without paging every span through model context. Because Phoenix is open source, the whole surface is yours to read, configure, or turn off. When you self-host, the queries run against the SQLite or Postgres database you already operate, not against a copy in a vendor’s cloud. Phoenix’s MCP settings page. Code mode is on by default, the server URL is ready to point a client at, and each client has a one-line connect command. Related resources: Start with the Remote MCP Server docs https://arize.com/docs/phoenix/integrations/remote-mcp , then see Meet PXI https://arize.com/blog/meet-pxi/ , coding agent tracing and evaluation https://arize.com/blog/open-source-coding-agent-tracing/ , and what’s next for Arize Phoenix https://arize.com/blog/from-observability-to-context-whats-next-for-arize-phoenix/ . For the broader stack, read building agent evals from traces https://arize.com/resources/agent-evals-from-traces/ and the glossary entries for Model Context Protocol MCP https://arize.com/glossary/model-context-protocol-mcp/ and trace https://arize.com/glossary/trace/ . What SQL adds to Phoenix’s MCP server Observability tools have always helped teams understand what’s happening. Now your agent can query that data directly and bring back the answer it needs. Letting the database do the counting, instead of moving every row somewhere else first, is one of the oldest lessons in working with data. Now agents can use that lesson, too. SQL is the foundation because it is general: it can answer the questions nobody anticipated, including the ones you invent next week. We built this so the agent reading your traces can move from collecting pages of data to asking precise questions of it. Point it at your own traces, and tell us what it gets right and where it struggles. If you have feedback, reach out in the Phoenix community Slack https://join.slack.com/t/arize-ai/shared invite/zt-3ta2horqe-QTB9OhHVgqx9rc7AjwRJdg .