Does your developers need another MCP?
Many Platform Engineering teams are creating MCP for their dev team but, when is it a good idea?
AI, AI, AI, all over the place.
Your CEO, CTO, and even your CPO are telling you:
Use the AI as much as possible!
Or this other (my favourite)
So will be able to deliver faster than before!
I will not jump into this debate (today), but into another: the development of the in-house services that implement the Model Context Protocol, to be used by AI Agents in the IDE of the developers.
Iโve seen many folks in Platform Engineering teams start writing MCP-based services meant to be used by the dev teams, and I wondered:
Hey, does this actually solve a problem for the dev teams?
In todayโs issue, I want to share with you my vision about when an in-house MCP-based service makes sense.
Before jumping into it, I just wanted to let you know that I am writing another newsletter on how to move from Cloud Native foundations to AIโpowered platforms. You can subscribe here ๐๐ป
Now, letโs get back to our business.
First of all, is this an automation?
Platform Engineering teams are meant to provide frameworks, CI/CD workflows, libraries, processes, and best practices to the Software Engineering teams so they can ship value to customers fast.
Platform Engineering teams have a great responsibility: choose the right solution so that Software Engineering teams will embrace and onboard the solution smoothly.
Since Software Engineering teams work with IDEs, and thanks to the existing integration between IDEs (VS Code, IntelliJ) and AI Agents, or existing IDEs like Cursor or Windsurf, one of the steps that could make sense is:
Letโs create an MCP-based service so developers can use it from their IDEs.
This is a great approach.
However, Iโve seen many Platform Engineering teams failing on this. Why?
๐๐ผ They implemented an MCP-based solution when the feature teams needed just an automation.
Do not mix AI with automation; they are different things.
So, next time you think the solution is an MCP-based service, ask yourself the following:
Can the work be done by an automation?
Is an in-house MCP-based service needed?
Look at this huuuge list of MCP servers available, many of them are official from their providers.
So, another question to ask yourself?
Will my MCP-based service solve a problem that isnโt already solved by existing MCPs?
Iโve intentionally made that question plural.
Connecting multiple MCP-based services to tools like Cursor or Windsurf already allows an AI Agent to solve problems that span multiple sources.
In fact, AI Agents can already orchestrate across the configured MCPs to resolve those problems.
So the real question is:
Why add another MCP that acts as a wrapper?
Maybe yes!, maybe no!
Iโve raised a couple of reflections that now your brain is trying to plug and play with the rest of your ideas. In order to help you, I will now list when it makes sense to create an MCP and when it does not.
When does an in-house MCP-based service not make sense?
Small organizations (1โ2 teams) where the operational overhead of the MCP outweighs the benefits.
Top priority: developer speed and minimal friction (you prefer direct adapters in the IDE).
High team autonomy: with very different rules and an aversion to centralization, the MCP will become a source of political friction.
When the cost of maintaining adapters/compatibility outweighs the benefits, e.g., too many vendors with unstable APIs.
When does an in-house MCP-based service make sense?
You have >=10โ20 teams with different policies and want global consistency (rulesets, RBAC, auditing).
You need correlation/dedupe between findings from multiple scanners (SAST, SCA, linters, Sonar, etc.) to prevent one bug from appearing as three.
Compliance/audit requirements: logging who automated what, blocking pull requests based on corporate policy, and evidence retention.
Youโll want to enforce cross-functional policies, like legal or privacy rules affecting all repositories, and enforce controlled downgrades when providers fail.
Letโs wrap up for today.
โจ Summary
Keep this in mind:
๐๐ผ Just because you can implement an MCP-based service to solve a problem doesnโt mean you should.
From there:
Make an assessment of the problem you need to solve.
Is it something you can solve with automation?
Be sure you have the right expertise in the team to implement these kinds of tools.
Thanks for your support and feedback, I really appreciate it!
Youโre the best! ๐๐ผ
๐๐ง ๐บ๐ฐ๐ถ ๐ฆ๐ฏ๐ซ๐ฐ๐บ๐ฆ๐ฅ ๐ต๐ฉ๐ช๐ด ๐ฑ๐ฐ๐ด๐ต, ๐ต๐ฉ๐ฆ๐ฏ ๐ค๐ญ๐ช๐ค๐ฌ ๐ต๐ฉ๐ฆ ๐. ๐๐ต ๐ฉ๐ฆ๐ญ๐ฑ๐ด!
๐๐ง ๐บ๐ฐ๐ถ ๐ฌ๐ฏ๐ฐ๐ธ ๐ด๐ฐ๐ฎ๐ฆ๐ฐ๐ฏ๐ฆ ๐ฆ๐ญ๐ด๐ฆ ๐ธ๐ช๐ญ๐ญ ๐ฃ๐ฆ๐ฏ๐ฆ๐ง๐ช๐ต ๐ง๐ณ๐ฐ๐ฎ ๐ต๐ฉ๐ช๐ด, โป๏ธ ๐ด๐ฉ๐ข๐ณ๐ฆ ๐ต๐ฉ๐ช๐ด