DEV Community

Roman V
Roman V

Posted on

Agent-readable API testing for Cursor and Windsurf: introducing API Workbench

#vscode #testing #api #cursor

API testing has moved into the editor. A lot of backend and full-stack developers now keep requests next to their code, run them from VS Code, and ask Cursor or Windsurf to help debug what changed.

But there is a frustrating gap: most API clients are still built only for human eyes.

Postman, Thunder Client, and similar tools can show a nice response panel. That is useful when you are looking at the screen. It is much less useful when your AI coding assistant needs to understand what happened. The agent cannot reliably read a custom webview, click through tabs, infer which assertion failed, or connect a 400 response to the route handler it just edited.

So the workflow usually becomes manual:

  1. Run the request.
  2. Read the response yourself.
  3. Copy the important bits into chat.
  4. Ask the assistant to fix the code.
  5. Repeat.

That breaks the whole promise of agentic development. The assistant can edit code, run tests, and inspect logs, but your API client output is still stuck behind a human-facing interface.

API Workbench is a VS Code extension built for that missing handoff. It runs HTTP requests from plain .http and .rest files, then writes structured API test results that Cursor, Windsurf, Claude Code, and other coding agents can read directly.

The Problem with Existing Tools

Before API Workbench, an assistant might only see something like this:

The request failed in Thunder Client. It returned 400. I think the email field was rejected.
Enter fullscreen mode Exit fullscreen mode

That is vague. The agent has to guess what endpoint failed, what payload was sent, what assertion was expected, and whether the backend or the test is wrong.

Agent-readable Reports

With API Workbench, a failed collection produces a report like this:

{
  "schema": "api-workbench-agent-report-v1",
  "verdict": "FAIL",
  "collection": "users.http",
  "environment": "local",
  "summary": "2/3 requests passed, 5/6 assertions passed",
  "action_items": [
    "POST http://localhost:3000/users - expected status 201, got 400"
  ],
  "requests": [
    {
      "name": "Create user",
      "verdict": "FAIL",
      "method": "POST",
      "url": "http://localhost:3000/users",
      "status": 400,
      "failures": [
        {
          "assertion": "status equals 201",
          "expected": "201",
          "actual": "400"
        }
      ],
      "response_body": "{\"error\":\"email is required\"}",
      "request_body": "{\"name\":\"Ada Lovelace\"}"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

That is the difference. The agent can now see the route, method, status, failed assertion, response body, and request payload in one stable schema. It can move from "something failed" to "the create-user request is missing an email field, and the test expects 201."

API Workbench also writes readable labeled output for quick inspection:

REQUEST: POST http://localhost:3000/users
STATUS: 400 Bad Request
DURATION: 42ms
BODY_JSON: {"error":"email is required"}
Enter fullscreen mode Exit fullscreen mode

How It Works

Requests live in .http files, committed alongside your app. Separate requests with ###, reference environment variables from .env files using familiar {{variable}} syntax.

### Create user
POST {{base_url}}/users
Content-Type: application/json

{"name": "Ada Lovelace", "email": "ada@example.com"}

### Get user
GET {{base_url}}/users/1
Enter fullscreen mode Exit fullscreen mode

Run a single request via CodeLens, or run the whole file as a collection. Reports land in .api-workbench/reports/ as both Markdown and .agent.json.

MCP Integration

API Workbench exposes its runner as MCP stdio tools, so agent workflows can trigger and read collection runs directly — no human in the loop required. This means your CI agent can run the full API test suite, parse the structured report, and open a PR with a fix, all in one pass.

Features at a Glance

  • Send HTTP requests from .http and .rest files
  • Run all requests in a file as a test suite
  • Generate flat .agent.json reports under .api-workbench/reports/
  • Labeled output for agents: REQUEST, STATUS, DURATION, BODY_JSON
  • Environment variables from .env files with {{variable}} syntax
  • Collections and environments sidebar in the activity bar
  • Response viewer: Body, Headers, and Raw tabs
  • MCP stdio tools for agent-driven test runs

Get It

API Workbench is MIT-licensed and open source. The v0.1.0 beta is available now:

  • GitHub Releases (VSIX manual install): sapph1re/api-workbench
  • VS Code Marketplace and OpenVSX listing coming soon

To install the beta today: download api-workbench-0.1.0.vsix from the release, then run:

code --install-extension api-workbench-0.1.0.vsix
Enter fullscreen mode Exit fullscreen mode

Or in Cursor/Windsurf: open the Extensions sidebar → ... menu → "Install from VSIX".

The fastest test: run a failing endpoint, export the agent report, and ask your assistant to fix the backend from the report alone.

If you are building for agentic IDEs, structured output from your tools matters. API Workbench is one piece of that — keeping the tight inner loop between request, response, and assistant tight enough to stay in flow.

Top comments (0)