You are asking two questions at once
These two questions often get mixed up, but separating them usually makes things much clearer.
The first question is what agent-ready means. My Wired for Agents standard lists four requirements: a documented API, an MCP server, programmatic authentication, and discovery that works from your main domain. You either meet all of these or you do not. There is no partial credit. If you want to say your product is agent-ready, you must meet all four, including the second one.
The second question is whether your product needs to be agent-ready at all. This is a business decision, not something the standard can answer. For many products today, the honest answer is no, or at least not yet.
This page focuses on the second question. If you have already decided you need to be agent-ready, the standard will guide you on what to build.
The line that decides it
Does an agent need to perform actions in your product, or just read information from it?
Acting includes creating, changing, buying, booking, cancelling, or sending: anything that changes your system. This is what a connector is for, and there is no real substitute.
Reading means looking up information, answering questions, or comparing options. A clear public API with good documentation usually covers these needs, and models can handle standard HTTP APIs well when the documentation is solid.
Anthropic, one of the protocol's creators, says in its build guide that if you already have a public API or CLI that the model can use directly, you can skip the connector. Since they have the most to gain from adoption, their advice carries a lot of weight.
Six cases where the answer is no
- If you do not have a good API yet, adding a protocol on top of missing authentication, unstable identifiers, and undocumented errors will only carry those problems forward. Build the API first. This investment pays off even if you never add agents, which is not true for the server.
- If your use case is just read-only access to public content, a clear API, a good specification, and working discovery will give you most of the benefits, without needing an install step or ongoing authentication maintenance.
- If you plan to auto-generate a tool for every endpoint, think again. Having eighty tools is worse than none, because the descriptions use up the model's context and lead to more mistakes. If you are not going to curate the tools, it is better not to ship the server.
- Sometimes, what you really need is knowledge, not actions. Many early servers were just documentation in protocol form. In these cases, it is better to provide conventions, workflows, and guidance as instructions instead of tools.
- If your API is already behind a cloud gateway, services like Azure API Management, Google Cloud API Gateway, and Amazon Bedrock AgentCore can expose your OpenAPI-described API as an MCP server without custom code. Just enable it and curate the endpoints.
- If you cannot fund evaluation and maintenance, it is a problem. A server that is not tested against real model behavior will have hidden issues, and the specification changed a lot in July 2026.
When the answer is clearly yes
There are three situations where you clearly need an MCP server. In each case, something needs to happen reliably, without a person clicking a button.
- Agents need to make changes in your product for a customer, and it is important that these changes are done correctly.
- If your customers are already asking for this, or a partner requires it, that is the most common real reason to build an MCP server, and it is a perfectly valid one.
- If your competitors have already launched an MCP server and buyers are comparing products, you may need to follow suit. On 26 September 2026, I found that twenty-one well-known products, including Stripe, GitHub, Linear, Notion, Sentry, PayPal, and Vercel, had live, authenticated endpoints. You can check this yourself: request one of their URLs, and if you get a 401, it means the server is live and asking for login.
Check the cheap thing first
Before making any decisions, spend some time on the fourth criterion. Most products fail here, but it is usually the easiest and cheapest to fix.
Begin at your main domain and try to find the entry points as a machine would, without logging in. Is there a specification at a stable URL? Does it require a login to access? Do your advertised URLs actually work, or does one return a 404 because it moved years ago? Can a machine get credentials without human help?
Many products that are thinking about adding a server actually have a broken entry point instead. Fixing this is inexpensive, helps regular integrators as well as agents, and is required before moving forward.
Where this page is biased
I build MCP servers, teach workshops about them, and wrote the standard. So, the six reasons above are especially worth considering. They are the ones that reduce my own workload.
One thing to note about my own standard: it requires an MCP server, while Anthropic's guidance says you can skip it if you have a good public API. These are not exactly the same. The standard defines what agent-ready means, not what every product should do, and I think it is better to acknowledge this difference.