Connect your coding agent to the Endform MCP server, then ask questions about the test history for the repository you are working in. The agent can compare trends, inspect individual executions, and open the telemetry from a failed attempt without you copying data out of the dashboard.
The conversations below are representative examples. Your results will use your own tests and Endform history.
Example conversationWhat are our flakiest tests?
You
What were our flakiest tests over the last seven days? Look into the worst one and tell me why it flakes.
Tool call:query_analytics·passing test runs with retries, grouped by test, last 7 days
Tool call:query_samples·recent retried executions of the flakiest test
Tool call:get_otel_trace·inspect telemetry from two failed attempts
Tool call:get_otel_trace·compare another failure from the same test
AI response
checkout.spec.ts › saved card › completes payment was the flakiest test this week. It passed in 18 runs, but 6 of those runs needed a retry.
The failed attempts have the same pattern: the test clicks Pay now immediately after the saved card request finishes, but before the form enables the button. The successful retries wait long enough for that state transition. Both traces show the first click targeting a disabled element; there is no corresponding POST /payments request.
I would replace the fixed delay before the click with an assertion that the button is enabled:
Which individual tests have the biggest effect on our test runtime? Check whether any have become slower recently.
Tool call:query_analytics·average test duration grouped by test, last 30 days
Tool call:query_samples·recent executions of the slowest tests
Tool call:query_analytics·daily duration trend for the leading slow test
AI response
reports.spec.ts › exports a yearly CSV is the largest individual bottleneck at an average of 48 seconds. It was averaging 29 seconds at the start of the month and has climbed steadily since August 8.
The sample runs show that browser setup is stable; almost all of the increase is spent waiting for the export request. organization.spec.ts › deletes a workspace is second at 33 seconds, but its duration has not changed materially.
I would investigate the yearly export endpoint first. Because Endform runs tests in parallel, reducing this longest test is more likely to shorten the overall feedback loop than optimizing several already-fast tests.
Example conversationTriage today's failures
You
Summarize today’s test failures. Group related failures together and tell me what to investigate first.
Tool call:query_analytics·failed test count grouped by test, last 24 hours
Tool call:query_samples·latest failed executions and their ordered attempts
Tool call:get_otel_trace·inspect a representative checkout failure
AI response
There are 14 failed test runs across three groups:
Checkout API unavailable: 9 failures. Three checkout tests fail after the same POST /payments 503 response. This is the highest-priority issue because it affects every browser project and retries do not recover.
Profile menu timing: 4 failures. These pass on retry and share a locator timeout. Treat this as one flaky-test issue.
Visual assertion: 1 failure. The settings-page screenshot differs only in WebKit and did not retry.
Start with the payments service or its test environment. The representative trace shows the UI behaving normally up to the failed API response, so changing the Playwright assertions would only hide the underlying outage.
You can make these questions more specific by naming a branch, commit, Playwright project, test file, title, or time window. The complete historical data tool reference is in Endform MCP server.
