spec v0.1
EN

Why MCP-first

Why MCP-first

UI-first thinking hits structural limits, six theses on why agent-ready capability architecture is the more consistent answer.

Classical software development thinks in interfaces first: customer list, project page, upload button, invoice form, calendar view. For humans, that makes sense. For AI agents, automations, and external systems it is the wrong abstraction model.

An agent should not need to know which page a button is on.

The core problem

What an agent really needs

An agent does not navigate interfaces. It calls capabilities. The relevant questions are:

  • What actions exist?
  • What inputs does an action expect, what outputs does it deliver?
  • What permissions are required?
  • Which action is risky or irreversible?
  • When does it need to check back with the user?
  • What is audited?

UI-first software answers none of these questions. MCP-first software answers them all.

Klassisch

  1. Webapp
  2. Mobile App
  3. Admin UI
  4. API
  5. Automation
  6. AI-Integration

MCP-first

  1. Domain Model
  2. Action Layer
  3. Permission Layer
  4. MCP Tools
  5. MCP Resources
  6. MCP Workflows
  7. Audit Layer
  8. Webapp · Mobile · Admin · API · Automation

Thesis 1: AI agents do not use software like humans

Humans click, scroll, read, and interpret. Agents need structured capabilities that can be called directly and securely.

The second approach is deterministic, typed, permission-checked, and auditable. The first produces fragile browser automation that breaks with every UI update.

Example: Schedule a follow-up
  • schedule_follow_up(contactId, projectId, datetime, note)
  • contacts.search(query, tenantId)
  • reminders.create(contactId, datetime, note, assignedTo)
  • calendar.find_free_slot(participantIds, duration, after)

Thesis 2: The user interface becomes one of many clients

In the past, the UI was the primary access point to software. In the future there will be several equal access points, all accessing the same capability layer:

  • Human via web app
  • Human via mobile app
  • AI agent via MCP
  • Automation via worker
  • Third party via API
  • Internal systems via events
  • CLI via action layer

Whoever builds the web app first and retrofits the rest builds the same action layer multiple times, each time slightly different, each time with its own permission logic.

Thesis 3: Software without agent capability becomes hard to integrate

When software only works through interfaces, fragile workarounds inevitably emerge:

  • Browser automation and screen scraping
  • CSV imports and manual copy-paste processes
  • Semi-automated workflows
  • Custom solutions per customer or integration project

These workarounds break on UI changes, do not scale, and cannot be audited. MCP-first removes the reason for their existence by making the system structurally controllable from the start.

Thesis 4: The best interface for many tasks is no interface

Many tasks are dialogic, contextual, and workflow-based, they no longer need a page:

“Create a summary of all open deals.” “Which customers should I contact today?” “Check whether any documents are missing for this employee.” “Create a report on all projects with risk.” “Compare the last two payroll runs.”

For these tasks, a conversational agent with access to a capability layer is more efficient than any page with filters and tables. The prerequisite: capabilities are cleanly modeled, typed, and annotated with risk levels.

Low Generate summary, Medium Create document, Critical Payroll export, the system must know these differences.

Thesis 5: MCP-first reduces duplicate development

When a feature is built first as an action, every client can use the same action , without duplicate implementation:

create_project(name, templateId, ownerId, tenantId)

This single action is usable from:

  • Web app
  • Mobile app
  • Admin UI
  • MCP agent
  • CLI
  • Worker
  • Import process
  • Integration
  • Test suite

This not only reduces effort, it eliminates inconsistencies between clients that otherwise accumulate over time.

Thesis 6: MCP-first enforces better architecture

Whoever builds MCP-first must automatically model more cleanly. Every capability needs:

  • clear domain actions with unambiguous user intent
  • typed input and output schemas
  • clear permissions and error handling
  • defined side effects
  • audit events and protection levels

This forces clear assignment of domain responsibility before a single line of UI code is written.

Example: What every capability must describe
  • Input Schema, typed, validated
  • Output Schema, deterministic
  • Permission Scopes, which role may call
  • Risk Level, low / medium / high / critical / forbidden
  • Side Effects, external impact, yes or no
  • Audit Event, what is logged
  • Confirmation Policy, autonomous or human approval

API-first was for developers. MCP-first is for agents.

API-first was for developers.

Software that is built first as a fully described, permission-checked, and audited capability system is simultaneously better for humans, better for agents, and better for everything in between.