Which is the cheaper mistake: paying an outside team for a server you did not need, or asking your own developer to learn a new protocol on top of a system nobody in the company ever documented? Most founders assume the second option is free. It is not. I run IndiaNIC, a software company founded in 1998, and my view after this series is that the choice to build in-house or hire MCP developers turns on two questions, and neither of them is budget.
This is the tenth and final article in the series. The earlier nine explained the protocol, the security model, the cost and four industries. This one is narrower and more awkward. It is about what you actually do on Monday morning, with the team you already have, and with the one task that annoys somebody in your company every single week.
Three things founders believe about MCP servers that are wrong
The first belief is that a server is a big project. Most first servers are smaller than the spreadsheet they replace. The Model Context Protocol documentation defines an MCP server as "a program that provides context to MCP clients", and the things a server can offer are only three: tools, resources and prompts. A useful first server can expose two read-only tools and nothing else.
The second belief is that this work needs an AI specialist. That one costs companies the most money, in my opinion, because it sends a simple integration job to an expensive team. MCP runs on JSON-RPC 2.0 over a local process or an HTTP connection. The documentation is blunt about the boundary: MCP "focuses solely on the protocol for context exchange and it does not dictate how AI applications use LLMs". Any competent backend developer who has written a REST client has already done the harder version of this.
The third belief is that hiring a partner means losing control of the thing. It means that only if you let it. You can ask for the repository, the licence and the credentials on day one, and a partner who hesitates on any of those three has answered a different question than the one you asked.
The two questions that actually decide build or hire
Question one. Is there somebody already on your payroll who knows the target system well enough to say what happens when a call to it fails at two in the morning?
Question two. Can the person who owns the process, not the developer, sit down for two hours and decide what the assistant may do without asking permission?
If both answers are yes, build it yourself and keep the money. A no on the first question means hiring buys you knowledge of an unfamiliar system. Should the second answer be no, hiring buys you something stranger and more valuable, which is an outsider with no internal politics who can make your team finish an argument about permissions. I have seen that argument sit unresolved for months inside a company and get settled in a single afternoon once a third party was in the room asking for a decision.
Here is the part the whole series has been building towards. The widely held view that the code is the hard part of an MCP server is simply wrong, and I will accept the cost of being wrong about that if someone proves otherwise.
The code is the cheap part. The sentence that says what the assistant may do without asking is the expensive part.
Everything I have written about secrets, permissions and human approval comes back to that one sentence. Write it badly and a careful developer builds an unsafe tool. Write it well and an average developer builds a safe one.
| Do not let the first tool write anything. The most expensive mistake I see is a first server that can change records before anyone has watched it read them for a week. Ship read-only tools first, then add one write tool with a confirmation step. |
Should I build, hire, or start with a skill?
There is a third path, and on most weeks it is the right one. Write the procedure as a skill before you write any server code. The Claude Code skills documentation describes a skill as a SKILL.md file with instructions that Claude adds to its toolkit, invoked directly as a slash command, and it notes that the body of a skill "loads only when it's used". A skill costs you an hour. A server costs you weeks.
If you want the longer arithmetic behind those durations, I set it out in the article on what an MCP server costs to build. Every number there and here is my estimate from our own delivery work, offered as a range, and not a measured benchmark.
What should I ask an MCP development partner?
Will you keep one system per server?
One server should talk to one system. Ask the question plainly and listen for whether the answer is a design principle or an improvisation. A partner who offers to put your orders, your invoices and your email into a single server is offering you one set of credentials with the combined blast radius of three.
Does every state change stop for a confirmation?
Reading is safe. Writing is not. The protocol has a client-side primitive for exactly this, called elicitation, which the documentation describes as allowing servers to request more information from users or "ask for confirmation of an action". Ask how the partner implements that, and what the tool does when the user says no.
When my team built byline, our own open-source server that publishes articles to Ghost and WordPress, we spent the first days on HTML validation and assumed that was the difficult part. It was not. The difficult part arrived the moment we asked which fields the tool may change on a live post without anyone confirming, and settling that took longer than writing the code to do it. The rule we ended up with sits in the repository README in plain words: nothing fails silently, and every tool returns a result or an error naming the API and its HTTP status. A partner worth hiring will put the same question to you in week one, and will not be satisfied with a vague answer.
How does the server fail, and who hears about it?
A silent failure in an automation is worse than an outage, because nobody goes looking for it. Ask what the error message contains. If the answer does not include the name of the system that failed and the status code it returned, the partner has not operated one of these in anger. You can see the pattern in our byline repository if you want a reference to point at.
Who owns the approval rules, and do we get the repository?
The approval rules belong to your business, never to your vendor. Ask for them as a written document you can change later without a developer. Ask also for the repository under a permissive licence such as MIT, and ask whether the code has any dependency on the partner's own hosting. If you cannot run it yourself, you did not buy a server. You rented one.
What should I bring to the first conversation?
Bring four things, and nothing else. A slide deck will waste both parties an hour.
- The one task that hurt somebody last week, described in the words that person used, not in the words a consultant would use.
- The system that task lives in, and the name of whoever holds the admin credentials for it.
- Your answer to the permission question: what may the assistant do without asking, and what must always stop and wait for a human.
- One thing that must never happen automatically, under any circumstances. The shorter your list, the faster the build.
I believe the permission answer is the part that takes longest in almost every project, and it is also the part no partner can write for you. We can draft it, argue with it and tighten it. We cannot decide it.
A seven-day plan to start this week
- Day one. Write down the task that cost somebody an hour last week. One paragraph, their words.
- Day two. Name the system it lives in. Find out who holds the credentials, and whether the system has an API at all.
- Day three. Hold the permission conversation. Two hours, the process owner in the room, one page of output.
- Day four. Write a SKILL.md with the steps as plain markdown, and run the procedure by hand against it for a day.
- Day five. Connect a real server so your team can see one work. The reference implementations maintained by the MCP steering group include Filesystem, Git, Fetch, Memory and Time, and the reference server repository also says you can browse published servers on the MCP Registry.
- Day six. Decide. Use the table above, the two questions, and nothing that arrived in your inbox.
- Day seven. Either open a repository with two read-only tools, or send one page to a partner containing your task, your system and your permission answer.
Notice that six of those seven days contain no code. That is deliberate, and it is the difference between a server that gets used and a server that gets demonstrated once.
Where IndiaNIC fits, said plainly
IndiaNIC does this work. We were founded in 1998, we have more than 500 AI-empowered experts across four continents, and we work from Ahmedabad, Dubai and Beverly Hills. AI Agents and Custom AI Services are two of the services we offer, and the README of our own byline repository describes us as the team that builds MCP servers and AI agents into other people's workflows for a living. If a conversation would help, write to hello@indianic.com or use our contact page. If you would rather build it yourself with your own developer, this series is the whole method, and that outcome suits me equally well.
The series, and the question I would ask you back
Ten articles, one argument. It starts with how MCP servers, skills and plugins actually fit together, then gets practical in how to build your first MCP server. The protocol version documented through 2026 is 2026-07-28, and it will move again, which is the main reason I keep telling people to start with one small task rather than a platform.
So here is my question for you, and I would genuinely like the answer. What is the one task in your company that you would hand to an assistant this month, and what is the one thing you would never let it do without asking you first? Write it in the comments, or better, put both sentences in front of your team this week and see whether they agree with you.
Frequently asked questions
Should I build my first MCP server in-house or hire MCP developers?
Build in-house when a developer on your payroll already knows the target system and the process owner can give real time to the approval rules. Hire MCP developers when the system is unfamiliar to your team, when those rules need an outsider to force a decision, or when the first server must work correctly on the first attempt.
Can I get value without building an MCP server at all?
Yes, and most companies should try this first. Write a SKILL.md. According to the Claude Code skills documentation, a skill is a markdown file with instructions that Claude adds to its toolkit and loads only when it is used. If the written procedure still helps after a week of real use, then build the server.
What should an MCP development partner hand over at the end?
A repository you can read and run yourself, under a permissive licence such as MIT, with no dependency on the partner's hosting. Alongside it, ask for the tool list, the approval rules as a document your team can edit, error messages that name the failing system and its status code, and one handover session.
