Agent Tools: Auto-Generating APIs for LLMs

The hardest part of building AI agents is usually not the LLM. It is getting that model to do useful work inside real applications.

I keep coming back to the same annoying scene, staring at a web app’s network tab, trying to reverse-engineer undocumented API calls so an agent can do one basic task. That friction might be getting smaller. A team at Frigade showed an approach where a browser agent watches an authenticated session, observes the app’s own network calls, and turns those calls into agent tools.

That is interesting because it cuts around the usual integration mess. Instead of hand-wiring every endpoint, auth flow, and schema, the agent learns from the app as it runs.

The problem with existing apps

AI agents run into the same wall over and over. Most existing software was not built for agent use. So you end up dealing with one of these problems:

• Undocumented or inconsistent APIs: Many internal APIs are a “spider web of confusing APIs and services” with no clean OpenAPI spec or even decent docs. You are left guessing endpoints, parameters, and response shapes.
• Security complexity: Auth is all over the place, JWTs, cookies, custom headers, or all of them at once. Passing that to an agent without breaking user context or permissions gets messy fast.
• Brittle browser automation: The fallback is Playwright or Selenium. It works until the UI changes. It is slow, fragile, and “burns a lot of tokens” when the LLM has to interpret what is on screen. It also struggles with dynamic content, CAPTCHAs, and unexpected layout changes.

So even if the model understands the job, getting it to actually do the job inside an app is still a custom integration project.

How Frigade’s approach works

The idea is simple and kind of clever. Do not start with documentation that probably does not exist. Let the agent watch a real user use the app.

The agent runs inside an authenticated browser session and observes the API calls the web app makes to its backend. Other projects like Integuru use a similar approach by capturing network traffic to a HAR file and generating API clients.

Here is the flow:

1. In-browser observation: The browser agent monitors network requests while a user interacts with the app, fetching data, submitting forms, whatever the app is doing.
2. Recipe generation: For each observed API call, the agent generates a “recipe” that includes:

• the API endpoint and HTTP method
• the authentication method needed, including how to retrieve tokens or cookies
• the input schema for POST and PUT requests
• the expected response schema
• a human-readable description of what the tool does

3. Self-updating tools: Those recipes become tools for the AI agent. If the app’s API changes, the agent can observe the new call and replace the old recipe.

That last part is what got my attention. The idea of an auto-generated “MCP server” that keeps itself current is hard to ignore if you have ever maintained a brittle integration.

This turns an app’s internal API into structured tools an LLM can call. No explicit API docs required. No huge manual integration layer. The result is an assistant that can “securely call the existing API endpoint for inviting users without proxying or relaying through a third party”.

Demos showed this working with Jira, Spotify, and Hacker News.

Why this matters

If this works well, it changes the shape of the work.

Instead of spending weeks wiring up a CRM API, sorting out auth, and mapping schemas by hand, you could let the agent learn those interactions much faster. That is the appeal.

A few practical upsides stand out:

• Rapid prototyping: You can get agent behavior into internal tools or SaaS products faster.
• Less maintenance: API changes do not instantly break everything if the agent can re-observe and regenerate the recipe. That is a lot better than traditional integrations that “break immediately when endpoints change”.
• More useful agents: The agent can work through the app’s own APIs, not just public APIs or flaky browser clicks. Saying “invite my teammate to my workspace” and having the system call the right internal endpoint is a much better path than trying to click through the UI.

That said, this is not magic. The team behind it said “every application is intrinsically different” and that “graphql was by far the worst API to work with in standardizing the recipes”. I believe that immediately.

The bigger point is still solid. Turning observed network behavior into tools is a real path forward for agent integrations, especially when the API is missing, incomplete, or just painful to work with. And yes, traditional APIs still matter for stable, high-volume transactions. But when speed matters, or the official integration story is bad, browser execution has a real edge. That hybrid approach, API calls plus browser access, has been shown to outperform using only one of them.

If you are trying to add AI to an existing product, this is the part to watch. I would much rather have an agent learn from the live app than hand-code every interaction myself.

Until next time, happy coding 👨‍💻
– Patricio Marroquin 💜