A Model Context Protocol (MCP) server is the door through which an AI agent uses your product: it lists a small set of tools, such as search, read a record, create an order, and the agent calls them on behalf of a person inside ChatGPT, Claude, VS Code or whichever host the person is using. Most product teams will be asked about one this year. This is the guide we use when a client asks us whether to build.
Five signals that say build it now
Your customers already ask an agent questions your product could answer. Look at support tickets and sales calls for “I asked ChatGPT about…” If people are asking an agent about pricing, availability, compatibility or policy, the agent is answering from whatever it scraped, and you are not in the conversation.
Agents are already scraping you. Check server logs for agent user agents and for crawls of pages a person would never read in that order. A scrape is an MCP server you did not design, run by someone else, with no authentication and no record of what was asked. Our founder’s survey of MCP servers for websites found seven tools whose whole purpose is to crawl someone else’s site for an agent.
Your product is a system of record. If other tools need to read from or write to you, agents will need that too, and they will do it through MCP rather than through a bespoke integration per tool.
Your API already exists and is well-shaped. An MCP server is mostly tool design over an API you already have. If the API is clean, the server is weeks of work, not months.
Your competitors are in the directories. The Claude connector directory and the ChatGPT app store are distribution. If a competitor is listed and you are not, an agent asked for “a tool that does X” will recommend them.
Three signals that say wait
Nobody is asking yet. If your logs show no agents and your customers show no interest, a short assessment is cheaper than a build. We can usually tell in a week.
Your API would embarrass you. If every call needs five others to make sense, fix that first. An agent will expose the gaps faster than any developer.
You cannot say what a wrong answer costs. An agent will sometimes pick the wrong tool or the wrong argument. If you do not know what happens when it does, and who approves anything irreversible, you are not ready to let it act.
What a good first server looks like
- Three to six tools, not thirty. Each named and described so a model picks the right one. Descriptions are where servers fail: one study of 856 tool descriptions found at least one defect in 97.1% of them.
- Read before write. Search and fetch first. Actions come once you have seen how agents use the read tools and have an approval step for anything irreversible.
- Compact results. Every field you return costs the person’s tokens and the model’s attention. Return what the next step needs.
- OAuth 2.1 from the start. The hosts expect it. Put an identity provider behind it and carry the person’s permissions into every tool call, so the agent can never do more than the person it acts for.
- Built for more than one host. Each host applies its own rules to names, annotations, timeouts and payload sizes, and they conflict. The rules, as they stood on 1 October 2026, are summarised in what each AI host requires of an MCP server.
- Tested like software a model will use. Conformance, host rules, evaluation sets that check the right tool gets picked, load, and injection through tool results. What exists for that, and what does not, is in testing an MCP server.
A decision table
| Situation | Our advice |
|---|---|
| Customers ask agents about you, API is clean | Build now: a two-week design sprint, then a production server |
| Customers ask agents about you, API is messy | Fix the three worst API seams, then build read-only tools |
| No agent demand yet, strong product | Run a one-week assessment; instrument logs; revisit in a quarter |
| Internal data and tools for your own staff’s assistant | Build, but behind your identity provider, with per-user permissions |
| Marketplace or booking business | Build search and availability first; actions after an approval flow exists |
What it costs
A design sprint of about two weeks produces the tool design, the authentication design and a working prototype against one host, so you can see an agent use your product before committing to the production build. The production build depends on your API and the hosts you target. We quote it fixed-price after the sprint. The service is described at MCP servers and AI integrations.