Short answer: build one when your team keeps asking AI tools questions that only your own systems can answer, and those answers need to be trusted. Do not build one because it is the interesting new thing. A production MCP server is mostly permissions, scoping, and logging, not model work, and a first version with a handful of read-only tools ships in weeks.
If you want the plain-English version of what MCP is and how it fits with company data, read our guide Your Business Data, On Demand first. This post is the next question: should you build one, and what does it actually involve?
The one-sentence version of MCP
The Model Context Protocol is a standard way for an AI app to reach outside tools. Instead of wiring a one-off connection for every model and every system, your server exposes approved tools (read a customer record, search documents, check an invoice, draft a follow-up), and any AI app that speaks the protocol can use them. It is a connector standard, not a database and not a model.
The signal that you need one: the Slack test
Look at the questions your team asks each other in Slack or Teams during a normal week.
- "Has that invoice been paid?"
- "Which jobs are scheduled tomorrow and who is on them?"
- "What did we quote this customer last time?"
- "Which leads have nobody replied to?"
If the answers live across three or more systems (CRM, accounting, calendar, docs, a field app), and someone spends part of every day looking them up, that is the signal. An MCP server turns those lookups into tools an agent can call, so the question gets answered where it was asked, with a link to the source.
If your questions are all answerable from one system that already has a good AI feature, you probably do not need your own server yet. Use the vendor's.
What a production MCP server actually includes
The demo version is ten lines of code and one tool. The version a business can rely on has a different shape. These are the parts that take the time:
Organization and role scoping. Every tool call has to know which company and which person is asking, and return only what they are allowed to see. If more than one team or client shares the server, that scoping belongs in the database layer (row-level security), not in the prompt.
Authentication. The agent proves who it is acting for. Tokens are stored encrypted, never in source, never in an error message.
Read-first tool design. Small, specific, read-only tools beat one giant "do anything" tool. Start with lookups. Add drafting. Add writes last, and only behind approval.
Human approval for anything that changes a record. A draft follow-up is fine to generate. Sending it, updating a deal, or changing a schedule waits for a person to say yes.
Audit logs. Every call, who asked, which tool, what came back. This is what makes the system trustworthy and what lets you fix it when it is wrong.
Rate limits and failure handling. External APIs go down. The server should fail clearly, not silently return stale data.
None of this is exotic. It is the same discipline as any internal API, applied to a new kind of client.
What a first version looks like
A sensible first MCP server has five to ten read-only tools that answer the questions from the Slack test. Examples we see repeatedly:
- Look up a customer and their open items
- Search approved documents and quote the source
- Check invoice or payment status
- List what is scheduled for a date and who owns it
- Find leads or tickets with no reply in N days
That scope is a focused first project. Our published planning range for a focused first project is four to eight weeks, and you can see the ranges on our timeline answers page. The first version proves the pattern. Write tools, approvals, and more systems come in the second pass once the team actually uses it.
Build, buy, or wait?
| Situation | Reasonable call |
|---|---|
| Your questions live in one system with a decent AI feature | Use the vendor's connector, wait on your own server |
| Questions span several systems and people look things up daily | Build a small read-only server |
| Records are messy, duplicated, or nobody trusts them | Wait. Fix the data first |
| You already have internal APIs | Build. An MCP server is a thin layer on top |
| You need writes across systems from day one | Build, but stage it: reads first, writes behind approval |
The "wait" row matters more than people expect. An agent on top of messy records does not clean them up. It answers wrong faster, and with more confidence.
What it costs
We do not put a single price on an MCP server because the number is driven by how many systems you connect, how clean the data is, and whether you need approval gates. The honest way to get a number is the same as any project: a short discovery pass, then a written scope. Our published ranges for that are on the pricing answers page.
FAQ
Do we need to build our own MCP server, or can we use existing ones?
Use existing ones for the tools they cover well. Build your own when the valuable answers live in your systems and nobody else's connector reaches them with the right permissions.
Can an MCP server change data in our CRM or accounting system?
It can, when that path is built on purpose. The safe pattern is read first, draft second, human approval third, then write, then log. Do not ship write tools in the first version.
How long does a first version take?
A focused, read-only first version fits our four to eight week planning range for a first project. Larger, multi-system builds run longer.
Does it lock us into one AI vendor?
No. That is the point of a protocol. The same server works with any AI app that speaks MCP, so you can change models without rebuilding your connectors.
What is the biggest mistake teams make?
Starting with write access and a giant general-purpose tool. Start narrow, read-only, and scoped, and let the logs tell you what to add next.
The bottom line
An MCP server is worth building when it replaces daily lookups across systems with trusted answers in the place your team already works. The engineering that makes it trustworthy is scoping, auth, approvals, and logs. Get those right in a small first version and the rest is expansion, not rescue.
Ideas Realized builds and runs MCP servers in production, for our own operations and for client systems. If the Slack test describes your week, the first step is a short call to map which systems hold the answers.