Your Software Needs an MCP Server, Not Just an API

A few weeks ago I wrote that software without an API is going to struggle. Salesforce’s Headless 360 announcement at TDX 2026 did not just validate that take, it raised the bar past it. The question is no longer whether your software has an API. It is whether an autonomous agent can actually use it.

The Original Post

A few weeks ago I posted something that felt pretty obvious to me at the time: If your software doesn’t have an API… you’re going to struggle. Not “maybe struggle.” Not “eventually consider it.” Struggle.

And now… Salesforce just dropped their Headless 360 announcement (their “Agentic Experience”). Like… yeah. Exactly. This is what I was talking about.

I’m not even trying to do a victory lap here (okay maybe a small one 😆)… but when companies at that level start making moves like this, it’s not experimental. It’s where things are going.

Because the reality is… your platform cannot be tied to your UI anymore. That worked before. It doesn’t now. Your software has to connect to: other platforms mobile apps third-party tools internal systems and now… AI agents

And AI agents especially don’t care about your UI at all. They care about one thing: Can they interact with your system cleanly? If the answer is no… you’re already behind.

I’ve seen people push back on this too… like “well not everything needs to be headless.” Yeah… I agree. But having APIs as a first-class, required part of your system? That’s not optional anymore. That’s table stakes.

At Active Logic, we’ve been building API-first software since day one. Not because it sounded cool… but because locking your entire platform to a UI never made sense long-term. Now we’re watching the rest of the market catch up in real time. Which is always an interesting place to be.

Anyway… I’ll drop my original post in the comments if you want to see what I said a few weeks back.

Going Deeper

What Salesforce Actually Shipped

At TDX 2026, Salesforce rolled out Headless 360, which makes “everything on Salesforce” reachable as an API, an MCP tool, or a CLI command, with more than 60 new MCP tools and 30 preconfigured coding skills so that agents in Claude Code, Cursor, Windsurf, or VS Code get live access to the platform. They also introduced an Agentforce Experience Layer that separates what an agent does from how it renders, so the same underlying action can surface inside Slack, Teams, ChatGPT, Claude, Gemini, or any client that speaks MCP. Salesforce is calling the whole package the Agentic Experience, and once a company of that size ships it as a product tier, everyone downstream has to react.

The nuance a lot of the commentary missed is that this is not a rebrand of API-first. It is a new architectural commitment. Raw REST endpoints are table stakes now. The new bar is making your capabilities discoverable, typed, scoped, and safe for an autonomous consumer to invoke without a human translating each call into glue code.

What an MCP Server Actually Is

The Model Context Protocol was introduced by Anthropic in late 2024 as an open standard for how AI systems connect to external tools and data. By March 2026, Anthropic reported over 10,000 active public MCP servers and 97 million monthly SDK downloads, and the protocol was handed off to the Agentic AI Foundation under the Linux Foundation with Anthropic, OpenAI, and Block as cosponsors. That trajectory is the real signal. Every major model provider now speaks MCP, which means every serious agent will expect to find you behind one.

Structurally, an MCP server is a thin layer that sits in front of your existing API surface and exposes three things to any compliant agent:

A catalog of tools the agent is allowed to call, each with a schema and a machine-readable description of what it does and when to use it
A set of resources, typically read-only data the agent can reference without burning tokens on a full API fetch
A set of prompts or workflows, which are higher-level recipes that chain tools together for common jobs the product already understands

The distinction that matters for a product owner: a REST API is a menu written in developer dialect, and a human picks items off it by writing integration code. An MCP server is the same menu translated for an agent, with the context, scopes, and guardrails the agent needs to pick the right tool and call it correctly on the first try. One is consumed by engineers over weeks. The other is consumed by LLMs over seconds.

Agent-First Is Not a Synonym for API-First

API-first was about exposing capability. Agent-first is about making that capability legible to a non-deterministic consumer who will retry, chain, and make decisions you did not script. In practice that shifts a few design assumptions:

Tool descriptions are product copy now. An agent reads your tool description and decides whether to call it. If the description is vague, the agent picks the wrong tool or asks the end user a clarifying question that should not have been necessary. Write each one like a shelf label in a store the agent cannot see.
Scopes matter more than ever. An agent acting on behalf of a user should have a narrow, auditable set of permissions. If your auth model is one API key with full access to everything, the first time an agent behaves unexpectedly against a production account will not be a debugging story, it will be an incident report.
Idempotency is non-negotiable. Agents retry. They will hit your create-order endpoint twice because the first response came back after their timeout, and if you cannot handle that safely you will ship duplicate records the agent cannot undo.
Errors are prompts. A 400 that says invalid_request makes an agent guess. An error that says field 'email' is required and must be RFC 5322 compliant lets the agent fix its call and keep moving. Your error messages are now part of your agent-facing interface, not just your developer experience.

None of this is new. It was just easier to ignore in an API-for-developers world, because a human integrator would file a ticket and work around the gap. An agent will not. It will either succeed or stall, and a stalled agent is a product that feels broken to the customer paying for it.

Why Most Software Will Struggle to Retrofit This

Headless 360 exists because Salesforce spent years internalizing that the UI is a consumer of the platform, not the platform itself. Most SaaS companies did the opposite. They built the UI first and grew an API underneath it like a vestigial organ, which is why so many vendor APIs cover roughly 40% of what the UI can do, stop at the boundaries of the feature team that built each endpoint, and return different field names depending on which subsystem you happen to hit.

Retrofitting that kind of surface into an agent-grade MCP server is not a weekend project. It requires normalizing data models, consolidating auth, writing honest tool descriptions for every capability, building retry-safe operations, and publishing an OpenAPI or MCP manifest that is actually kept in sync with the runtime. Based on our experience building custom software from scratch, teams that already had an API-first architecture can reach agent-first in a quarter. Teams that did not get to decide how much more technical debt they are willing to carry before a competitor with a cleaner surface becomes the default integration target for every agent in their market.

The Practical Question

The useful question for a software vendor is no longer “does our API cover the core workflows.” It is: if an autonomous agent representing our customer picks us out of a tool catalog and tries to complete a real job, does it succeed, fail safely, or stall. If you have not tested that end-to-end in the last 60 days, you do not have an answer yet, you have a guess.

What This Means for Your Business

Audit whether your product can be driven by an agent, not just integrated with one. Integration is a developer writing glue. Agent-driven means an LLM invoking your capabilities with no human translation step in between.
Treat your tool descriptions and error messages as product surface. They are read by the agents that decide whether to use you at all, and a bad description is the new 404.
If you live on Salesforce, Headless 360 is not optional reading. Your competitors are already mapping which of their workflows become new revenue once they are exposed as MCP tools inside the Agentic Experience.
If you are building custom software or platforms on cloud infrastructure today, agent-first is the design default now, not a future phase. Designing the REST API and the MCP surface together is cheaper than retrofitting either one later. Our MCP server development practice exists for exactly this: making your platform consumable by the agents your team already uses.

API-first got you a product developers could integrate with. Agent-first gets you a product agents will actually choose.

Your Software Needs an MCP Server, Not Just an API | Active Logic Insights