Dekita

Stop your agent from inventing APIs: rebuild the contract from a HAR file

ai agents api devtools

Your agent just told you it called GET /api/v2/users/{id}/preferences. That endpoint does not exist. Now you have a Tuesday problem: prove what the real API looks like, fast, without trusting either the agent or your memory.

The fastest reliable answer is usually already on your disk. Export the traffic from your browser, rebuild the surface from the capture, and make the agent argue against evidence instead of inventing endpoints.

# 1. Capture the flow in Chrome DevTools (Network tab, right-click, "Save all as HAR with content")
# 2. Point REA at the capture
npx --yes rea-agents@latest setup
rea doctor

Then ask your agent to run REA's capture-inspection tool against the HAR file. What comes back is not a guess. It is an inventory of requests with the capture records attached to every claim.

What REA is, in one paragraph

REA (morluto/rea) is an open-source MCP server plus CLI that gives a coding agent the backends for reverse engineering: native binaries (Mach-O, ELF, PE, .app bundles), Go binaries, JavaScript and Electron apps, .NET assemblies, APK/IPA/ASAR archives, websites observed through a Chrome DevTools endpoint, and saved network captures (HAR, mitmproxy). Static analysis of JavaScript, .NET, websites, and captures needs no extra engine. Deep native analysis needs Hopper (commercial, demo mode works), Ghidra 12.1.2 with JDK 21, or IDA. Requirements: macOS 12+, Ubuntu 24.04+, Fedora 41+, or 64-bit Arch; Node.js 22.19+ or 24.11+; Windows x64 is experimental and Ghidra-only.

The repo sat mostly unnoticed from its creation in April 2026 until the first week of October. Then it took the number one spot on GitHub Trending for five of the seven days from October 6 to 12, with single-day star gains above 25,000 on consecutive days. Secondary trackers disagree on exact counts (some report just over 113,000 stars on October 12, others 115,000 with 25,000 forks), so treat those numbers as scale, not precision. The Hacker News thread drew 769 points and 327 comments. dev.to published multiple setup guides within days.

The workflow that matters: capture to contract

Most coverage sells "rebuild any app." Skip that. The part you can use this week is the API reconstruction path, and it works because every step stays anchored to recorded traffic.

Step 1: capture cleanly. In Chrome DevTools, reproduce the user flow and save all requests as HAR with content. Use a test account. HAR files can contain live tokens.

Step 2: inspect the capture offline. REA's network-capture tool reads the HAR without refetching recorded URLs, validates each entry, and preserves request and response bodies with their digests. It structurally excludes authorization headers, cookies, and URL credentials from the evidence it hands back.

Step 3: read the api-surface view. REA groups requests by HTTP method, origin, and inferred path template, and converts common dynamic values into placeholders:

Each group cites the source records and flags mixed statuses or content types.

Step 4: promote placeholders to parameters. Feed the inferred templates into your API tooling. The dev.to guides pair REA with Apidog: import the same HAR, turn {numeric} and friends into actual path parameters, enable the mock, and write assertions against captured response shapes. Client code then runs against a reconstruction before it touches the real service.

Step 5: make the agent argue with evidence. Now the prompt changes. Instead of "call the preferences endpoint," it becomes "every endpoint you use must appear in this inventory with its capture record attached." An agent that cannot cite a record has not earned the call.

The evidence rules worth copying

The reason this workflow resists hallucination is not the model. It is the shape of the output:

The project's own docs are careful about the last boundary: the api-surface view is an inferred inventory, not a formal specification. It does not claim to know the API schema or server handlers. That is the honest framing, and it is the one your contract tests should encode.

Before you install: three things to settle

1. Pin the version. Seven minor versions shipped in nine days (3.2 on October 3, 4.0 on October 5, 5.0 on October 7, 6.0 on October 8, 6.1 through 6.4 between October 9 and 11). The project's always-bump-minor policy means a minor may contain breaking changes; the 6.2 migration changed the structure of every MCP result. If you script against REA's JSON output, pin the version, read the changelog before upgrading, and test your integration against the new format.

2. Isolate untrusted targets. REA is a connector, not a sandbox. Its own security policy says the local provider bridge is not a sandbox: opening an untrusted binary runs its parsing with your user permissions. Dynamic features (process capture, browser observation, runtime inspection) are disabled by default and need explicit environment variables plus per-call approval; file-based evidence commands only work inside directories you approve. Analyze untrusted targets in an isolated environment, the same way you would isolate any agent's tool calls.

3. Respect the license. The project is MIT-licensed and scoped to lawful reverse-engineering research, analysis, and reconstruction. Reverse engineering for learning and interoperability is common practice, but some license agreements and jurisdictions restrict it. Recreate ideas and behavior, not copyrighted code or assets.

Two limits the docs are honest about

Local does not mean private. Analysis runs on your machine, but the README's FAQ notes that the agent's model provider still receives the tool results under its own data policy. If your capture contains sensitive response bodies, decide what leaves the machine before you start, not after the inventory is built.

Budget the agent tokens. Deep investigations can consume a lot of agent tokens. The published case studies are scoped questions — one function, one data path — not whole-application rebuilds. Scope the question before you point the agent at a target, and expect the cost to scale with the breadth of the ask.

What to do this week

  1. Save one HAR from a flow your agent keeps getting wrong.
  2. Run the capture inspection and read the api-surface view against the agent's version of the same flow.
  3. Add one assertion per disputed endpoint, citing the capture record, before you touch production code.

Where I am unsure

I have not run REA against a large capture set myself; the workflow above is assembled from the project's own documentation and multiple dev.to guides, and the case-study numbers (a DX-Ball reconstruction passing 3,205 original x86 test cases and reproducing all 63 compiled function bytes; an early side-by-side where a vanilla agent's gap was narrow and REA ran slower) are the project's and reviewers' claims, not my measurements. The star-count surge is well documented across trackers; whether accuracy holds outside the three published case studies is not yet established by anyone independent.

Sources

This post was written with AI assistance. The author is responsible for its content.

← All writing