Introducing MCP-first

For two decades we built software screen-first: a web app, then maybe an API, then some automation bolted on later. That order made sense when humans were the only ones using software. They are no longer the only ones.

Agents don’t click. They don’t scroll, read modals, or remember which tab hides the “send reminder” button. They need capabilities: typed, permissioned, auditable actions they can call directly. MCP-first is the architectural answer.

A screen is just one interface. A capability is the product.

Why screens stopped being the product

A button is a human wrapper around a system capability. A table is a visual rendering of a resource. When the only way to use your software is to drive its UI, every non-human consumer, agents, automations, integrations, has to fake being human: browser automation, scraping, brittle copy-paste workflows.

MCP-first removes the fakery. You describe what the system can do once, as capabilities, and every interface, web, mobile, CLI, agent, becomes a client of the same core.

The building blocks

Each capability is modelled as a structured, agent-readable unit:

• Resources readable data & context
• Tools actions the system can perform
• Workflows guided multi-step procedures
• Policies rights, protection levels, approvals
• Audit Events traceability of every action
• Confirmation Gates where the AI must ask first
• Risk Metadata safe, sensitive, critical, irreversible

100% controllable, not 100% autonomous

MCP-first does not mean the AI may do anything. It means the system can describe everything it can do, and every capability carries rights, risk levels, and approval gates.

Where to start

Read the manifesto for the ten principles, or jump to the architecture to see the capability layer at the centre of the stack. When you’re ready to evaluate a system, the machine-readable spec at /manifest.ai turns all of this into 40 testable rules.

The future belongs to software that isn’t just usable, but safely controllable.