DEV Community: Loic Aron Mbassi Ewolo

I gave my Laravel API generator an MCP server

Loic Aron Mbassi Ewolo — Tue, 29 Sep 2026 11:06:34 +0000

Coding agents write Laravel code well. Ask one for a CRUD API and it will write the model, controller, requests, resource, policy, migration, factory, seeder and tests by hand, slightly differently every time, and you get to review all of it.

I maintain Laravel API Generator, a dev-only package that writes those files from a schema, with tests that pass and code that passes Pint. Version 4.0 gives it an MCP server, so the agent calls the generator instead of typing the files.

Two commands

The server runs on Laravel MCP, which needs Laravel 12.41 or later.

composer require --dev nameless/laravel-api-generator laravel/mcp
claude mcp add -s project laravel-api-generator -- php artisan api-generator:mcp

With -s project, Claude Code writes .mcp.json, which you can commit so the whole team gets the server. Cursor and other clients take the same command, php artisan api-generator:mcp, and in VS Code the extension registers it for Copilot's agent mode on its own.

The agent gets four tools:

Tool	What it does
`list-entities`	Returns each generated entity with its files, marked intact, edited or missing
`plan-api`	Lists every file a generation would create or update, with warnings, without writing anything
`generate-api`	Writes the files, from an api-schema document or an OpenAPI spec of the project
`add-fields`	Adds columns to an entity, with an incremental migration and in-place patches

The first two are marked read-only, so your client knows they change nothing. The server also ships a design-api prompt, which Claude Code offers as a slash command, and exposes the JSON Schema of the schema format as a resource.

Plan first

Here is the run from the video: /mcp__laravel-api-generator__design-api with one sentence, a library that lends books to members. The agent checked what already existed, drafted a schema and called plan-api.

Four entities, 56 files, no warnings, and a question at the end: generate it as is, or change something first? After the go, generate-api wrote everything and the 62 generated tests passed.

Your edits stay yours

The package records every file it writes in .api-generator/manifest.json. A file you changed since is reported as edited, and generate-api leaves it as it is ("kept": true in the result). The server never deletes a file and never runs a migration. Overwriting your edits with --force, deleting an entity and migrating stay on the command line.

In the demo, LoanService.php got a hand-written rule. Asked for a notes field on loans, the agent read the manifest, saw the edited service, ran add-fields as a dry run first, and the service came out untouched.

One gap showed up while filming: add-fields doesn't update the DTO yet, so the agent patched LoanDTO.php itself. That's the next fix on my list.

What the generated code looks like in 4.0

4.0 is a major release because the output changed. It needs Laravel 12 or 13, while Laravel 10 and 11 stay on the 3.x line.

Controllers bind the model from the route and start every action with the policy:

public function update(UpdateArticleRequest $request, Article $article)
{
    Gate::authorize('update', $article);

    $dto = ArticleDTO::fromRequest($request);

    return new ArticleResource($this->service->update($article, $dto));
}

The update rules start with sometimes, and the DTO remembers which keys the request sent, so a PATCH with a single field changes that field and nothing else. The index is paginated, filtered and sorted out of the box:

GET /api/articles?filter[status]=published&sort=-created_at&per_page=20

On Laravel 13, models declare their fillable columns with #[Fillable]. Enums are named after the entity and the field (ArticleStatus), and every generated file passes pint --test with the Laravel preset, which the CI checks on both Laravel versions.

The VS Code extension, redesigned

Not everyone drives an agent. The VS Code extension does the same work with a form, and 1.1 redesigns it.

The preview on the right comes from the package installed in your project, through a long-running php artisan api-generator:serve --stdio, so it shows exactly the files that will be written, diffs included. A database, a schema file, a Mermaid diagram, an OpenAPI spec and a plain description drafted by Copilot all end on the same review screen before anything is written.

After a generation, the panel runs the next steps in place: migrations, tests, seeding and the Scramble docs.

It's also on Open VSX for Cursor and VSCodium.

What it doesn't do

It generates code, and that's all. Autocompletion and navigation for Eloquent and Blade are the job of the official Laravel extension. The MCP server needs Laravel 12.41 or later. And the output is opinionated, with a thin controller, a service and a DTO: if your team writes CRUD differently, publish the stubs and change them, and api-generator:validate-stubs checks them.

Your Mermaid diagram is a valid input for a Laravel API generator

Loic Aron Mbassi Ewolo — Sat, 25 Jul 2026 14:45:40 +0000

Data models get designed in diagrams and implemented in code, and the two drift apart from day one. The diagram in your README says Post belongsTo Category; the code says otherwise; nobody notices until a migration fails.

The fix I landed on for laravel-api-generator: make the diagram the input. Two formats work, YAML and Mermaid.

YAML

# api-schema.yaml
options:
  pest: true
  postman: true

entities:
  Category:
    fields:
      name: string unique
    relations:
      posts: hasMany Post

  Post:
    fields:
      title: string
      content: text
      status: enum(draft,published) default=draft
      published_at: datetime nullable

php artisan make:fullapi --schema=api-schema.yaml

Look at what's missing: Post never declares belongsTo Category, and there's no category_id field anywhere. The generator synthesizes the inverse relation and its foreign key column. You declare one side, like you would explain it to a colleague, and both sides exist in the code.

The enum line generates the backed enum class, the model cast, Rule::enum validation and a factory that picks random cases. I wrote about that chain in more detail in part 1.

This is the one I use most, because GitHub renders it in the PR:

Mermaid

php artisan make:fullapi --mermaid=docs/erd.mmd

Both erDiagram and classDiagram work. Cardinalities map to the right Eloquent relations, UK markers become unique fields, a deleted_at column enables soft deletes. Markdown fences and comments are stripped, so a diagram pasted straight from an AI chat works as-is. Review the diagram in the pull request, merge, generate. No drift, because there's nothing to drift from.

The VS Code extension takes the same Mermaid input without the terminal, and it draws the reverse view too: an interactive diagram of your entities (zoom, pan) inside the editor. The diagram goes in, the API comes out, and the canvas shows you what actually exists.

[VISUEL 15 (fichier 13) : vraie capture du diagramme interactif de l'extension, habillée]

[VISUEL 10 (fichier 13) : split-screen diagramme Mermaid rendu / arborescence générée]

Custom primary keys propagate

Country:
  fields:
    code: string primary
    name: string
  relations:
    cities: hasMany City

This was the request that took me the longest in v3.6. City gets a country_code column typed like the key, ->references('code') in the migration, exists:countries,code in validation, and the model declares $primaryKey, $incrementing and $keyType. The generated tests use getKey() so the same suite passes with either key style. Polymorphic relations (morphTo, morphOne, morphMany) are supported in schemas too.

Day 30

Every scaffolder demos well on day 1 and gets deleted on day 30, because regenerating would wipe your manual work. So regeneration isn't the evolution path here. Patching is:

php artisan make:fullapi Post --add-fields="excerpt:text,seo_title:string"

This writes an incremental Schema::table migration with a down(), and patches $fillable, the casts, the PHPDoc, the validation rules, the factory and the resource in place. Your custom methods are not touched. Fields that already exist are skipped. The DTO and the tests are deliberately left alone and reported as manual follow-ups, because guessing there felt more dangerous than useful.

Practical notes

Dev dependency, MIT, generated code has no reference to the package. Works in CI and with AI coding agents; one YAML file describing the whole API turns out to be a much better target for an agent than "create twelve files". The extension mentioned above also adds a form builder with live preview, imports from a database or an OpenAPI spec, and one-click migrate, seed and docs.

Docs: https://nameless0l.github.io/laravel-api-generator/
GitHub: https://github.com/Nameless0l/laravel-api-generator
Part 1 (architecture): link · Part 2 (--from-database): link

If you have opinions about what a schema format should support, the issues are open. Mine changed three times while building this.

Turning an existing database into a documented Laravel API

Loic Aron Mbassi Ewolo — Wed, 22 Jul 2026 11:04:16 +0000

The projects I dread are the ones where the database is the only documentation. Twenty tables, foreign keys, years of production data, and either no API layer at all or a pile of copy-pasted controllers nobody wants to touch.

Writing models, controllers, validation and tests for twenty existing tables by hand takes days. This is the problem that made me add --from-database to laravel-api-generator:

composer require --dev nameless/laravel-api-generator
php artisan make:fullapi --from-database

The generator reads your live schema and produces, for each table, the same stack it builds in normal mode: model with full PHPDoc, thin controller, service, DTO, form requests with real validation rules, resource, factory, seeder, policy, and written tests (PHPUnit, or Pest with --pest).

[GIF demo-from-database.gif (voir fichier 12) : vraie exécution en terminal, pas Claude Design]

What the introspection actually reads

I spent a lot of time making this more than a column dump.

A VARCHAR(255) NOT NULL UNIQUE column doesn't just become a string field. It becomes required|string|max:255|unique:users,email in the form request and fake()->unique()->safeEmail() in the factory.

Foreign keys turn into relations on both sides: posts.user_id gives you Post::user(): BelongsTo and User::posts(): HasMany, both typed in the PHPDoc. On Laravel 11+ the generator reads the real constraints; it also falls back to the <table>_id naming convention for older schemas without them.

Pivot tables are detected (two foreign keys and nothing else) and become belongsToMany on both models, instead of generating a useless PostTag entity. Column pairs like commentable_type + commentable_id become a proper morphTo. Enum columns become native PHP backed enums with casts and Rule::enum validation. A deleted_at column switches the whole entity to soft deletes, restore endpoint included.

You rarely want all tables

php artisan make:fullapi --from-database --tables=posts,categories,comments

Two defaults exist to save you from yourself: migrations are not regenerated (the tables already exist; pass --with-migrations if you want them as code-of-record), and the users table is skipped so your customized User.php survives. --tables=users overrides that explicitly.

The payoff

The generated controllers are Scramble-friendly, so if you have Scramble installed, /docs/api serves browsable OpenAPI docs immediately. Add --postman and you can hand a collection to the frontend team the same morning.

If the team lives in VS Code, the extension runs the same import from a table picker, and its Open API Docs button closes the loop: it checks Scramble, starts the server if none is running, detects the port and opens the docs in the browser. It even offers to create .env from .env.example on a fresh checkout.

Legacy database at 9:00, documented and tested API at 9:15. The business logic still needs a human. The plumbing doesn't.

Notes

The package is a --dev dependency and the generated code doesn't depend on it, so you can treat it as a one-shot migration tool if that's all you need.

Docs: https://nameless0l.github.io/laravel-api-generator/
Part 1, on the architecture it generates: part1

If you have a schema that you think would break it, I want to see it. Weird databases are how this feature got better.

A complete Laravel API with clean architecture in 30 seconds, tests included

Loic Aron Mbassi Ewolo — Sat, 18 Jul 2026 20:23:24 +0000

I counted the files I create every time I add a resource to a Laravel API. Model, migration, controller, a form request, a resource, a factory, a seeder, a policy. If the project cares about architecture, add a DTO and a service class. Then the tests.

Twelve files before the first line of actual business logic. I got tired of typing them, so I wrote a generator. It's MIT, I maintain it solo, and v3.6 shipped this week.

One command

composer require --dev nameless/laravel-api-generator

php artisan make:fullapi Post --fields="title:string,content:text,status:enum(draft,published),published_at:datetime"

Output:

app/
├── DTO/PostDTO.php
├── Enums/Status.php
├── Http/
│   ├── Controllers/PostController.php
│   ├── Requests/PostRequest.php
│   └── Resources/PostResource.php
├── Models/Post.php
├── Policies/PostPolicy.php
└── Services/PostService.php
database/
├── factories/PostFactory.php
├── migrations/xxxx_create_posts_table.php
└── seeders/PostSeeder.php
tests/
├── Feature/PostControllerTest.php
└── Unit/PostServiceTest.php
routes/api.php  ← apiResource registered

[GIF demo.gif (voir fichier 12) : vraie exécution en terminal, pas Claude Design]

The VS Code extension: same engine, no terminal needed

[VISUEL 11 (fichier 13) : VRAI screenshot de l'extension VS Code, habillé ensuite dans Claude Design]

If you'd rather click than type, the free VS Code extension drives the same make:fullapi command, so the files are identical. You describe the entity in a form (fields, enums, relations, options) and a live preview shows the exact code before anything is written. Or you skip the form and import from your existing database, a YAML schema, a Mermaid diagram, or an OpenAPI/Swagger spec.

The button I always demo first is Open API Docs: it checks that Scramble is installed (and offers to install it if not), finds a running Laravel server or starts php artisan serve itself, detects the port, and opens the interactive docs of your new API in the browser. Migrations and seeding are one-click too, and if .env is missing the extension offers to create it from .env.example. You can go from an empty Laravel project to a browsable, documented, tested API without opening a terminal once.

The part I actually care about: the architecture

Plenty of tools can spit out a model and a migration. What I wanted was the layering I end up building by hand on every serious project. The generated controller is thin:

public function store(PostRequest $request)
{
    $dto = PostDTO::fromRequest($request);
    $post = $this->service->create($dto);

    return new PostResource($post);
}

Validation lives in the form request, business logic in PostService, and data crosses layers as a typed readonly PostDTO. When the project grows, the place where new logic should go already exists. That's the whole point.

Models your IDE can read

Each generated model comes with a real PHPDoc block:

/**
 * @property int $id
 * @property string $title
 * @property string $content
 * @property Status $status
 * @property \Illuminate\Support\Carbon|null $published_at
 * @property-read \Illuminate\Database\Eloquent\Collection<int, Comment> $comments
 */
class Post extends Model

So $post->title autocompletes in VS Code and PhpStorm without installing ide-helper. The generator already knows every field and relation at generation time; writing the docblock costs it nothing.

What `enum(draft,published)` produced

That one field definition created five coherent pieces:

App\Enums\Status, a native backed enum
the cast on the model
Rule::enum(Status::class) in both form requests
fake()->randomElement(Status::cases()) in the factory
$table->enum('status', [...]) in the migration

Before v3.6 the package just mapped enums to strings. Wiring the whole chain took longer than I expected, mostly because of the factory.

The tests are written, not scaffolded

This was my line in the sand. Most generators leave you empty test classes. Here php artisan test is green right after generation: index, store, validation errors, update, delete are all covered with real assertions.

it('creates a post', function () {
    $payload = Post::factory()->raw();

    $this->postJson('/api/posts', $payload)
        ->assertCreated();

    $this->assertDatabaseHas('posts', ['title' => $payload['title']]);
});

That's the Pest style, from the --pest flag. Without it you get PHPUnit classes with the same coverage.

Docs, Postman, auth

--postman writes a ready-to-import collection at the project root. The controllers are written so Scramble can build OpenAPI docs from them without annotations. --auth scaffolds Sanctum (register, login, logout, middleware on your resources).

There is also a --from-database mode that reverse-engineers an existing database into full APIs, but that deserves its own article.

Zero lock-in

The package installs with --dev and the generated code has no dependency on it. No base classes, no runtime helpers, nothing to use. You can remove the generator after generating and the app doesn't notice. If you don't like the generated style, publish the 24 stubs (php artisan vendor:publish --tag=api-generator-stubs) and edit whichever ones you want.

Where it stops

It scaffolds a clean REST baseline and then it's out of the picture. Your domain logic, your weird queries, your edge cases: still your job. The difference is that you write them inside a service layer that already exists, with baseline tests already passing.

Links

composer require --dev nameless/laravel-api-generator
php artisan make:fullapi Product --fields="name:string,price:decimal,stock:integer" --pest
php artisan test

Docs: https://nameless0l.github.io/laravel-api-generator/
GitHub: https://github.com/Nameless0l/laravel-api-generator
VS Code extension: https://marketplace.visualstudio.com/items?itemName=Nameless0l.laravel-api-generator

If you try it and something breaks, open an issue. Schema edge cases reported by users have driven most of the recent releases, and I'd rather hear about yours than guess.

DEV Community: Loic Aron Mbassi Ewolo

I gave my Laravel API generator an MCP server

Two commands

Plan first

Your edits stay yours

What the generated code looks like in 4.0

The VS Code extension, redesigned

What it doesn't do

Links

Your Mermaid diagram is a valid input for a Laravel API generator

YAML

Mermaid

Custom primary keys propagate

Day 30

Practical notes

Turning an existing database into a documented Laravel API

What the introspection actually reads

You rarely want all tables

The payoff

Notes

A complete Laravel API with clean architecture in 30 seconds, tests included

One command

The VS Code extension: same engine, no terminal needed

The part I actually care about: the architecture

Models your IDE can read

What enum(draft,published) produced

The tests are written, not scaffolded

Docs, Postman, auth

Zero lock-in

Where it stops

Links

What `enum(draft,published)` produced