From Six Lines to a Working Full-Stack App

Point a coding agent at a documentation server, hand it six lines about a shopping list, and half an hour later an ASP.NET Core API and a Vue 3 SPA are running against a seeded database. This post is that recipe: what you need, what to type, and what comes out.

The server is the part that makes it work. An agent on a framework it has never seen either writes what it remembers — confident code against an API that never existed, or existed three versions ago — or needs the documentation pasted into the chat and paid for on every turn. The Model Context Protocol gives it a third option: a reference desk it can walk up to, where only the answers travel. Regira runs one for its .NET packages and its @regira/modules front-end library at https://mcp.regira.com/mcp. Ten small applications were generated with nothing but that server as the source of framework knowledge — each run was told to set aside its memory and the other samples on disk — and they are public at github.com/Regira/Regira-Samples.

What you need

• A .NET 10 SDK, Node with npm, and git. Nothing else is installed by hand; the agent creates the solution, the SPA and the database. Installing and checking them, per operating system, is in Getting Your Machine Ready for a Coding Agent.
• An agent that speaks MCP over HTTP. The samples were built with Claude Code; Cursor, GitHub Copilot in VS Code and Claude Desktop connect to the same server, and their settings are in the supporting article.
• No account and no key. The packages restore from nuget.org and npmjs.com, the server answers anonymous callers, and Regira Entities' free tier covers a sample-sized domain: up to seven entity registrations.

One expectation to set: an agent run is not a build script. Two runs from the same brief give the same structure and different details, so this post promises the structure.

Step 1 — Point the agent at the server

One file at the root of the repository does it. An empty folder is fine:

{
  "mcpServers": {
    "regira": {
      "type": "http",
      "url": "https://mcp.regira.com/mcp"
    }
  }
}

Save it as .mcp.json. The first session in that folder asks you to approve the server; claude mcp list confirms it is connected.

Step 2 — Write the brief

Describe the domain: the concepts it holds and how they relate. The gaps you leave are deliberate — the plumbing between those concepts, from tables and DTOs to endpoints, paging and validation, is what the agent looks up on the server and glues together: filtering and sorting wired the documented way, an update that does not blank the fields your form never showed, seed data written through the same path a real request takes. Spell the plumbing out in the brief and you get what you described; leave it to the agent and you get the documented idiom.

The samples' briefs, each a prompt.txt, share one shape: a one-sentence purpose that names the folder, three or four bullets of domain, one line of visual direction. This is ShopMate's:

Create an app ShopMate/ (back-end & front-end), which offers services to run a Shopping list.

* A shopper can manage multiple shopping lists.
* A shopping list contains articles that are sortable and can be activated (need to buy)/deactivated.
* An article can have multiple categories and shoppers can filter them easily, text search included.
* A category can have multiple parent/child categories.

Use a modern mobile-first design with large touch-friendly controls, swipe actions and a minimal interface.

The adjectives are the load-bearing part: "sortable", "activated", "text search" and "multiple parents" each map to a named answer in Regira Entities, so they are cheap to ask for and expensive to leave out. The closing line steers the look of the SPA.

Three standing lines went with every brief, whatever the domain. The first sends the agent to the Regira server for anything Regira: an agent with several servers connected picks one by its tool descriptions, and "filter a list" fits a general documentation server — or its own memory — just as well, so name the one you mean (the wording for a project's instruction file). The second seeds the database through the entity services — around five hundred rows of the primary entity — which makes the app browsable on its first run instead of a screen of empty lists. The third asks for a README documenting the run, because the agent writes down what it did while it still remembers.

No brief asked for sign-in, yet four samples have it: the guide settles the auth mode in its first phase, and those four briefs name administrators next to employees or customers — users with roles. The other six stay anonymous. If you want sign-in, or want to be sure you get none, say so.

Step 3 — Let it run

Paste the brief and let the agent work. Its first read is the server's bootstrap guide, and that is where the reference desk stops being one: the guide does not describe the framework, it tells the agent how to build with it and how to prove each piece works before moving on. A golden path of eight phases, one checkpoint each, and no phase starts before the previous checkpoint passes.

The checkpoints run against the real thing, not a green build: phase 4, for instance, saves a few records through the running API and reads them back.

One habit in the transcript tells you the framework is being used rather than imitated: the agent does not write the Vue slices by hand. It runs the scaffolder that ships inside the npm package and fills in what a generator cannot know — a rule in the guide, not an instinct of the model.

What the scaffolder produces is deliberately plain: working lists, forms and navigation, styled like an admin panel. Restyling or replacing that shell is fair game, and the brief's last line invites it — as long as the behavior underneath survives the makeover, because that part is not decoration.

The reading stays frugal — a few dozen calls to the server per sample — and a sample-sized app takes about half an hour. Why the server can steer a model this precisely is the next post.

Step 4 — Run what came out

Every sample runs the same way, and so will yours:

# terminal 1 — the API creates its SQLite database on first run, seed data and all
cd ShopMate/backend/ShopMate.Api
dotnet run --launch-profile http

# terminal 2 — the SPA
cd ShopMate/frontend
npm install
npm run dev

The API opens Scalar at /scalar; dotnet run --launch-profile http -- --ResetDatabase=true starts over with a fresh, reseeded database. The SPA sends its calls to /api, which Vite proxies to the API; where that proxy targets the API's HTTPS port, as the scaffold writes it, start the API with --launch-profile https.

What is inside is the layout the guide prescribes, so you will recognize it across projects: one folder per entity, holding the model, the two shapes it takes over the wire, the object that says what can be searched, and a single registration that wires filtering, sorting, related data and the rules that run on save. Controllers stay thin because a base class does the work, and the seeder the brief asked for writes through the same services an API call goes through, so seeded rows are indistinguishable from typed-in ones. The SPA mirrors it: one slice per entity, registered in one place.

The brief named none of that structure. What each piece does, and why it is shaped that way, is what the Filtering and Writing in Regira Entities series are for; this post only needs you to recognize it when the agent hands it over.

Then click through it once yourself: add a list, tick off a few articles, filter by category.

If your setup differs

The recipe assumed Claude Code in an empty folder. Another client, an application that already uses Regira, a domain over the free tier or a machine without a network each need a line or two more, and they are in Connecting Your Coding Agent to a Documentation Server.

The trade-offs

What half an hour and a few hundred thousand tokens buys is the domain: the brief's bullets turned into entities, relations, filters, seed data and a UI that opens on them — the part you would otherwise write yourself, entity by entity. A template gives you an empty project and leaves that work where it was.

What you give up is determinism: there is no "regenerate", so commit what came out and treat it as ordinary code from then on. It is also code nobody has read yet — the checkpoints prove that the app works, not that the model named things the way your team would. And the free tier's ceiling shapes the domain model, which the agent will tell you rather than quietly go past it.

Docs: the Regira MCP server landing page, the Regira Entities framework, and the samples at Regira/Regira-Samples. Regira Entities is commercial with the free tier used throughout; the samples are MIT.

Versions: the samples pin Regira 6.4.0; the @regira/modules 6.5.0 scaffold proxies /api to the API's HTTPS port.