Your stack
AI agent for Next.js applications
Next.js blurs the client and server boundary, which is convenient to build with and awkward for tools that only see one side. Merlean reads the repository, so server actions and route handlers are as visible as pages.
What Merlean reads in a Next.js codebase
Merlean connects to your repository through GitHub or GitLab and analyses the application rather than recording a user clicking through it. In a Next.js project, that analysis draws on:
- App Router and Pages Router structure, including dynamic segments and route groups.
- Route handlers under
app/api, with their request parsing and response shapes. - Server actions, which are frequently where the real mutations live and are invisible to anything analysing network traffic alone.
- Form components and their validation schemas, including the server-side revalidation that follows a submit.
- Middleware, which often carries the authentication and redirect rules for whole route trees.
The result is a machine-readable model of what the application can do, which fields each action needs, which order multi-step work has to run in, and who is allowed to run it. That model is what user requests are resolved against.
Authentication and permissions
Merlean uses the session your application already issues, whether that is a cookie set by NextAuth or Auth.js, a JWT, or a token from an external identity provider. Middleware runs on Merlean's requests exactly as it does on a user's.
Worth knowing about Next.js specifically
- Server actions are the most common source of surprise. A mutation invoked directly from a component has no URL a network-level tool would ever see, which is why source analysis matters more here than in a conventional SPA.
- Caching and revalidation semantics are read, so Merlean can tell a user that a change is applied but a cached view may lag rather than reporting a phantom failure.
- Route handlers that return streams or React Server Component payloads are recognised and handled differently from plain JSON endpoints.
Getting started
Connect the repository, run the first analysis, and review what Merlean understood. Reviewing is the step worth spending time on: the analysis is derived from your code, so where it is wrong it is usually pointing at something genuinely ambiguous in the application.
Then add the widget with a single script tag, or expose the application over the Model Context Protocol so an AI agent your users already use can reach it.
Frequently asked questions
Can Merlean invoke server actions?
It executes through the endpoints your application exposes and understands server actions as part of the workflow model, so an action that is only reachable through a server action is still reachable.
Does it work with both App Router and Pages Router?
Yes, including mixed codebases part-way through a migration.
What about deployments on the edge runtime?
The runtime does not change anything. Merlean calls your deployed application over HTTP the same way a browser does.
See it against your own application
Merlean reads your repository and shows you what it understood before anything is exposed to a user. The fastest way to judge the fit is to point it at a real codebase.
Related
Add an AI assistant to your web app that actually does the work
Embed an AI assistant in your SaaS product that completes tasks instead of explaining them. One script tag, no per-feature integration code, works on any web stack.
Turn your web app into an MCP server
Expose your app to AI agents over the Model Context Protocol. Merlean derives the tools from your codebase, so agents act with your users' own permissions.
Merlean vs browser agents
Browser agents screenshot and click. Merlean reads the source and calls the endpoints. A comparison of reliability, speed, cost and fit.