For twenty years, using a service meant opening it. You went to the website, signed in, found the page, filled in the form. Every product competed for a tab.

That is changing. A growing share of people now start with an assistant and ask for an outcome: "find me a slot with a dermatologist next week", "what did we invoice this client in May", "reorder the filters we bought last time". If your service can take part in that conversation, it gets used. If it cannot, the assistant either answers from memory, which is often wrong, or suggests a competitor that can.

Four steps got us here. Each one is worth understanding, because together they explain what a service has to look like to be usable by an agent.

2023: ChatGPT plugins showed the demand

When OpenAI opened ChatGPT plugins in March 2023, the recipe was simple. A service published an OpenAPI description of its endpoints and a short manifest that explained, in plain language, what it was for. ChatGPT read the description and decided when to call it.

Two things became clear very quickly. First, people wanted this. Being able to ask for a restaurant table or a flight price inside a chat was obviously better than a tab hunt. Second, the plumbing was not ready. Discovery was a flat list. Every plugin had its own authentication story. The model often did not know which of forty plugins to use, and the experience varied wildly between services because the quality of the OpenAPI file and its descriptions decided everything.

Plugins were wound down in 2024 in favour of custom GPTs, but the lesson stuck: a description of your API, written for a model rather than a developer, is a product surface in its own right.

Late 2024: MCP made it a standard

The Model Context Protocol, published by Anthropic in November 2024, took the plugin idea and turned it into an open, vendor-neutral protocol. An MCP server exposes three kinds of things: tools an assistant can call, resources it can read, and prompts it can offer. Any MCP client, whether it is Claude, ChatGPT, a coding agent, or an internal assistant, can connect to any MCP server the same way.

The technical details matter less than the economic one. Before MCP, connecting a service to an assistant was a one-off integration with one vendor. After MCP, it is a single server that every client can use. During 2025 the major assistant makers adopted the protocol, and it became the default answer to "how do I make my product available to agents".

MCP also settled a few design questions that plugins had left open. Tools carry typed input and output schemas, so the model knows what it can pass and what it will get back. Servers can run remotely with standard OAuth, so a user can authorise a service once and use it from any client. And because the protocol is open, the tooling around it, from inspectors to gateways to hosting, is shared rather than rebuilt per vendor.

2025: connectors made it a one-click experience

A protocol is invisible to most people. What they see is a button. Claude's connectors, and the equivalent directories that other assistants added, package MCP servers so that an end user can add a service to their assistant in a click, sign in, and start asking.

This is the step that turned MCP from a developer topic into a distribution channel. A service that publishes a well-designed connector is discoverable inside the assistant, next to the tools people already use. A service that does not is simply absent from the conversation.

For a product team, the practical consequence is that "we have an API" is no longer the finish line. The question becomes: which five or ten things should an assistant be able to do with our product, how do we name and describe them so a model chooses correctly, and what must never happen without the user confirming it first?

2025 onwards: MCP Apps put an interface inside the conversation

The most recent step is MCP Apps, an extension to the protocol that lets a tool return an interactive interface rather than only text. Instead of the assistant describing three available appointment slots, the service can render them as a small, tappable card inside the chat. Instead of a paragraph about a shipment, a live tracking view.

ChatGPT's apps follow the same pattern, built on MCP underneath. The conversation stops being a text channel that sits in front of your product and becomes a surface where a slice of your product actually runs. The screen did not disappear; it moved into the assistant, and it got smaller and more focused.

What this means if you run a service

Put the four steps together and a clear picture emerges of what an agent-ready service looks like.

It exposes outcomes, not endpoints. A model does not want forty REST routes. It wants "search available slots", "book a slot", "cancel a booking". Good MCP tools are shaped around what a person would ask for, with a short description written for the model that explains when to use each one and what it needs.

It is honest about consequences. Reading data is cheap and safe. Creating an order, sending a message, moving money, or deleting a record is not. Agent-ready services mark those actions clearly and require an explicit confirmation step before the assistant performs them. The protocols support this; the discipline has to come from the service.

It handles identity properly. When a user asks an assistant to act on their account, the service needs to know which user that is and what they are allowed to do. Remote MCP servers with OAuth solve the mechanics, but someone still has to map assistant users to accounts and decide which scopes each tool needs.

It is documented well enough for a machine. Every one of these steps, from the plugin manifest onwards, depends on a description the model can read. Typed schemas, documented error responses, examples, rate limits, and idempotency behaviour are no longer developer niceties. They decide whether the assistant uses your service correctly, or at all.

It is operated, not just launched. An MCP server is production infrastructure. It needs hosting, monitoring, rate limiting, secrets management, and someone watching when a client changes how it calls tools. The services that win in this channel treat the agent interface with the same seriousness as their website.

Where to start

Most teams do not need to understand the protocols to take the first step. They need an honest look at their existing API through an agent's eyes: what could an assistant reliably do with it today, what is missing, and which actions need guard rails.

That is what our free Agent Readiness Audit does. It reads your documentation, proposes the tools an assistant would get, scores what is ready and what is not, and gives you a fixed price to have the MCP server built, hosted, and maintained under your own domain. It takes about two minutes and asks for no credentials.

The assistant is becoming the front door. The question for every service is whether it is standing behind it.