Operate LUNO from MCP

AI coding agents can now build much of an application for you. But they still need somewhere to put the data, forms, content, files, APIs, and business state.

Instead of asking the agent to build another backend, LUNO gives it one to operate.

Your coding agent can build the frontend. LUNO gives it a backend to operate.

MCP — Model Context Protocol — is the interface that makes that possible. It is not the backend itself. It is how an AI agent discovers and operates LUNO.

This article answers a practical question: how does an AI coding agent actually operate a backend? For the category definition, see /blog/what-is-ai-era-backend-platform. For why you should stop rebuilding backends, see /blog/never-build-backends-again.

AI coding agents can build applications

An AI coding agent is increasingly good at the application layer. In a typical loop it can:

User
 ↓
AI Coding Agent
 ↓
Generate application code
 ↓
Connect APIs
 ↓
Deploy application

That is real progress. UI, frontend code, application logic, integration glue, and deployment configuration are exactly where coding agents create leverage.

But applications still need backends

An application is not finished when the code compiles. It still needs data, content, forms, media, APIs, publishing, and operations — durable backend capabilities that live beyond one generated repo.

When the agent has no existing backend to operate, the path often expands:

AI Agent
 ↓
Generate backend
 ↓
Generate database
 ↓
Generate auth
 ↓
Deploy infrastructure

AI is rebuilding the backend for every project.

That is the opposite of /blog/never-build-backends-again. You get another stack to own, another ops surface, and another place where humans and agents diverge.

Why let AI rebuild the backend?

Rebuilding a backend for every app feels productive because the agent can scaffold quickly. It is still expensive in the only ways that matter after day one: ownership, consistency, and operation.

A better default is simple: give the agent an existing backend it can understand and operate, instead of asking it to invent one.

Give the agent an existing backend

With LUNO, the structure changes:

User
 ↓
AI Coding Agent
 ↓
MCP
 ↓
LUNO Backend
 ↓
Application

The agent does not generate a fresh backend for each project. It discovers and operates existing backend capabilities.

AI Coding Agent
      │
      │ MCP
      ▼
     LUNO
 Backend Platform
      │
      ├── Content
      ├── Forms
      ├── Media
      ├── API
      ├── Publishing
      └── Operations

That is the center of this article. LUNO is Backend Platform for the AI Era. MCP is the agent interface into that platform — not a substitute for the platform.

What MCP changes

MCP should not be explained as “just another API.”

An API exposes endpoints. MCP exposes operations an agent can reason about: tools, schemas, descriptions, structured inputs and outputs, errors, and capabilities.

An API exposes endpoints. MCP exposes operations an agent can reason about.

That does not mean MCP guarantees correct agent behavior. It means the backend can present operable work in a form agents are designed to use.

MCP is an agent interface, not the backend

A useful mental model:

                 LUNO
                  │
       ┌──────────┼──────────┐
       │          │          │
    Console      API        MCP
       │          │          │
     Human    Application   Agent

Different interfaces, same backend.

MCP does not replace the Console. Humans, applications, and AI agents become three classes of backend operator against one system of record.

That is the important shift. Backend consumers used to be humans and applications. In the AI era, agents join that set. See also /blog/console-and-api-same-record.

Agent-ready means understandable, not merely connected

Passing a tool list is not enough. Before an agent can finish useful backend work, it needs to understand:

- what already exists
- what it can create
- in what order to operate
- which dependencies matter
- which actions are production-impacting

Agent-ready does not mean “has an API.” It means the backend is understandable and operable by an agent.

MCP tool design affects how well agents can reason about those operations. Measurement and tooling details belong in dedicated benchmark / tool-design writing — this article stays on the operating model.

From tool calls to task completion

MCP connectivity is not task completion

Being able to connect to an MCP server, see tools, and complete a tool call is a prerequisite. It is not proof that the agent built the backend you asked for.

Completion looks more like this:

- expected resources exist
- schema is correct
- data exists
- publishing state is correct
- API returns expected data
- the application can consume the result

Connection is a prerequisite. Completion is the outcome.

Do not treat fewer MCP calls as the success metric. Ten calls that finish the task beat two calls that leave an incomplete backend.

The goal is not fewer tool calls. The goal is fewer unfinished tasks.

Discover → Plan → Execute → Observe → Verify

In development and verification, agents usually work in a loop:

Intent
  ↓
Discover
  ↓
Plan
  ↓
Execute
  ↓
Observe
  ↓
Verify
  ↓
Done

Observe is the underrated step. If an agent cannot inspect resulting state, it cannot detect missing fields, wrong configuration, or unexpected publish status.

That is why an agent interface needs more than mutation tools. It also needs tools that let agents inspect what changed.

Production governance is a different loop. High-risk changes may require:

Intent
→ Change Plan
→ Human Approval
→ Execute
→ Observe
→ Recover

Agent operation and production authority are separate concerns.

Development can be execute → observe → retry. Production may be propose → approve → execute → observe → recover. Details live in the Agent Governance series — start with /blog/agent-autonomy-without-production-authority.

Agent authority is not human authority

Authentication is not authorization

Do not frame MCP as “give your AI agent access to your LUNO account.” The better framing is: give the agent access to the backend capabilities it needs, within an explicit authority boundary.

Agent Key
  ↓
Who is calling?

Human Approval
  ↓
Who authorized this high-risk change?

An Agent Key answers who is calling. It does not mean every production mutation is automatically authorized. Making useful backend operations available while keeping authority explicit is the point — not handing unbounded production power to an agent.

A practical example

Suppose you ask an agent:

Build a corporate website backend with a contact form and a blog. Create one published blog post.

The useful path is not a human clicking tools one by one. The user describes the outcome. The agent figures out the backend operations:

1. Discover available backend capabilities
2. Create the required content model
3. Create the contact form
4. Configure fields / validation
5. Create the blog entry
6. Publish the entry
7. Verify the resulting backend state

MCP gives the agent the interface. The agent still needs to reason about the task. Good agent tooling is not about exposing more tools. It is about making the right work understandable and executable.

Coding agent vs LUNO

Compared with generating a backend per project:

This is not a claim that LUNO automates every backend concern. It is a claim about where ownership and operation should live.

Get started

Once the model is clear, setup is deliberately short:

1. Create or open a LUNO project
2. Create an Agent Key
3. Connect your coding agent (Claude Code, Cursor, or Codex — where supported)
4. Run MCP setup from your site repo
5. Ask the agent to inspect the backend
6. Let it create and operate the required resources
7. Verify the resulting state

Commands and environment variables belong in the technical docs. Start from the Agents path guide when you are ready to connect: https://docs.luno.rest/en/guide/paths/agents

Then give the agent an outcome, not a manual checklist of tool names.

If the backend is the unit of operation, it is also the natural unit of pricing — see /blog/pricing-without-seat-tax.

Conclusion

AI agents can write code.
But code is not the backend.

The backend is where the application's
data, capabilities, state, and operations live.

LUNO gives agents an existing backend.

MCP gives them a way to understand and operate it.

The result is simple:

The agent builds the application.
LUNO provides the backend.
Humans remain in control of authority.

Let the agent build the application. Don't make it rebuild the backend.

Build with your agent. Operate the backend through LUNO.