Open source API testing tools have a UI-shaped blind spot. Here is the category gap, and the 13-line fix.

Bruno is the fast desktop client with a Git-friendly .bru spec format, best for teams escaping Postman lock-in. Hurl is a single-binary CLI that runs plain-text files with chained requests and JSONPath assertions, best for CI smoke suites. Hoppscotch is the browser-native Postman alternative with a clean UI and a self-hostable stack. SoapUI is the veteran Java desktop app that still has the deepest SOAP and WSDL support. Karate DSL is a Gherkin-style BDD framework that collapses HTTP, WebSocket, and GraphQL testing into the same feature file. REST Assured is the Java library you drop into JUnit to assert on responses. Schemathesis is a property-based fuzzer that generates cases from an OpenAPI or GraphQL schema. EvoMaster does something similar but with a white-box evolutionary approach. Each is sharp at one slice of the category. The piece none of them own is UI-triggered API verification, where the browser session has already set the auth cookie and your test needs to fire an HTTP request inside that same context.

Because the #1 consumer of most product APIs is the product's own UI, not a partner. When a user clicks Connect Slack, the browser does a redirect, the backend exchanges a code for a token, writes a session cookie, fires a webhook, and renders a success state. A pure API test hits /api/integrations and asserts on the response shape. It never exercises the redirect chain, the cookie handoff, the CSRF state, or the webhook delivery. When the flow breaks in production, the API test is green and the UI test is green, because each tested its own half. The bug lives in the seam.

The http_request tool is registered in the same TOOLS array as navigate, click, and type_text. See /Users/matthewdi/assrt-mcp/src/core/agent.ts lines 171 to 184 for the tool definition, and lines 243 to 247 of SYSTEM_PROMPT for the pattern the agent is trained on. Inside a single #Case, the agent can click a Connect button, then call an external API to verify the side effect, then click another UI element to confirm the rendered state. There is no second runner, no handoff script, no token extraction step. The browser session, the fetch call, and the assertion all run in the same tool loop.

When you need them to, yes. The http_request tool accepts a headers object, so if you need to authenticate an internal endpoint, you pass the cookie or bearer token as a header. For external third-party APIs like Telegram, Slack, or GitHub, the typical pattern is to use the API's own token (bot token, webhook secret, personal access token) which is already the right scope for verification. The agent can pull that token from a test variable (the variables map at server.ts line 344 interpolates {{KEY}} placeholders) or from the page after the UI flow exposes it.

Yes. Bruno or Hurl are excellent for contract-level tests that belong in a pipeline gate before any browser boots. Schemathesis is the right fuzzer for catching 500s on malformed payloads. Assrt is the tool you reach for when the question is 'does this whole user journey work', and the journey includes both a button click and an HTTP side effect. A reasonable 2026 stack is Schemathesis for fuzzing, Hurl in CI for smoke, Bruno for local exploration, and Assrt for end-to-end scenarios that cross the UI-API line. They do not overlap enough to be competitive.

The Assrt MCP server is MIT-licensed at /Users/matthewdi/assrt-mcp/LICENSE. Playwright and @playwright/mcp are Apache 2.0. The Anthropic SDK is MIT. Cloud sync to app.assrt.ai is opt-in and gated by a UUIDv4 that acts as the access token (see scenario-store.ts line 8); run with an inline --plan and nothing leaves your machine beyond the LLM call. Compared to commercial AI QA platforms at $7.5K per month per seat that require uploading your DOM to their cloud, the bytes-out budget is the Anthropic token bill plus zero.

A single #Case in /tmp/assrt/scenario.md with numbered steps. For example: '1. Navigate to /settings/integrations. 2. Click Connect Telegram. 3. Copy the bot token from the confirmation dialog. 4. http_request GET https://api.telegram.org/bot<token>/getUpdates. 5. Assert the response contains a message from this workspace in the last 60 seconds.' The agent reads this like a QA engineer would. It picks element refs from the live accessibility snapshot for steps 1 through 3, fires a real fetch for step 4, and makes a structured assertion for step 5. All five steps run in one agent loop.

Both Cypress and Playwright let you make HTTP calls from inside a browser test, which is already closer to the right shape than a pure API tool. The difference is where the test lives and who writes it. With cy.request and APIRequestContext, the test is a TypeScript file with selectors, locators, and a compile step; a developer writes it and owns its decay. With Assrt, the test is a Markdown case with prose, no selectors exist in the file, and the agent picks elements at run time from the live page. Cypress and Playwright are right when you need deterministic per-action speed (about 1 second per action) and you have engineers who want to own .spec.ts files. Assrt is right when you want a scenario.md that a PM or QA lead can edit, run in 4 to 6 seconds per action, and still exercise the UI-API seam.

The agent makes one request per http_request tool call, with a 30-second AbortController timeout (agent.ts line 855). If the external API returns 429, the tool result is 'HTTP 429 Too Many Requests' plus the response body, and the agent sees that in its next turn. The usual pattern is either to back off in the scenario with a wait step before the API call, or to split the scenario into smaller cases that exercise one integration at a time. For high-volume verification, run the scenario against a staging endpoint or a mock server (WireMock, Mockoon, Prism) and let your contract tests handle the real rate-limited service.

Three layers. First, the agent only knows the URLs that are written into the scenario.md, so a scenario that only references localhost cannot accidentally fire at a production hostname. Second, the variables map at server.ts line 344 lets you pass an environment-specific base URL as a {{BASE_URL}} placeholder and keep the prose the same across dev and staging. Third, in CI you pass a scenarioId that was vetted in the web UI, and anything new needs a code-review approval before it reaches main. Nothing inside the agent will invent a URL you did not provide.