My favorite phase of building a company is when the market starts to converge on a standard set of requirements. Early on, every customer conversation is its own thing. People are still figuring out what they want, you are still figuring out what to build, and there is a strange middle stretch where you cannot tell whether you have found the shape of the market or just the shape of the last five customers you talked to.
Then something shifts.
I remember this happening at Rancher when suddenly every conversation was about Kubernetes instead of Mesos or Docker Swarm. Different industries, different company sizes, different geographies, and they are all asking for the same set of things. That is the moment I love. It means the category is real, the buyers know what they are buying, and the workload explodes because you are trying to pull customer requirements into the product every week.
We have hit that moment with MCP and skills governance.
Over the last month, I have been in calls with financial services teams, banks, airlines, ad agencies, crypto firms, semiconductor companies, payments companies, and private equity portfolios. The requirements list for an enterprise MCP platform is now consistent enough that I can usually guess what someone is going to ask before they ask it.
Here is the list.
1. A vendor-neutral control plane
Nobody is running one AI client. Every team I talk to has at least three in active use, usually some mix of Claude Desktop, Claude Code, Cursor, Enterprise ChatGPT, Copilot, Codex, Kiro, Gemini, and an internal chat client built in-house. If your governance model only works for one vendor, you do not really have governance. You have one vendor’s connector list and four other shadow IT problems.
The control plane has to sit in front of everything. There needs to be one place to register MCPs and skills, then define who gets access to what regardless of which client the user opens that morning. I wrote more about that in The Enterprise MCP Control Plane, but the short version is simple: enterprise adoption accelerates when the answer is governed access, not a blanket no.
👉 If you’re looking for a vendor-neutral MCP control plane, try Obot. Centrally govern MCP access across Claude, Cursor, ChatGPT, Copilot, and internal AI clients.
2. Identity-anchored access
Whichever identity provider you run, Okta, Entra, Google, Auth0, JumpCloud, that has to be the source of truth. RBAC needs to tie to IdP groups, not to a separate user list that somebody maintains by hand. When someone leaves the company, their MCP and skill access should disappear when their directory access disappears, not three weeks later when someone remembers to clean it up.
This requirement sounds boring, and it is. It is also one of the first things every security team asks about.
3. Tool-level permissions
Allow and deny at the MCP level is not enough. The pattern I hear constantly is some version of this: we want NetSuite, but block journal edits. We want Snowflake, but only specific query tools. We want our Git provider, but commenting can stay on while admin operations stay off.
The same upstream MCP has to be exposable in different forms to different groups. Teams want governed bundles made from subsets of tools. They want to rename tools when it helps. They want a way to resolve name collisions when five MCPs are stitched together. They need that granularity because it is the same level of granularity their compliance teams are already asking for.
4. Content filtering at the gateway
For regulated industries, this is the difference between we can pilot AI and we cannot. PII, PHI, financial data, and proprietary client information all create the same practical question: who ensures that sensitive data does not leave the building inside an MCP request?
Filters have to be configurable per tool and per server, not just globally. Block mode and redact mode are both useful, and they are useful for different reasons. Off-the-shelf detectors are helpful for common patterns, but every enterprise also needs custom filters for its own internal data. Nothing prebuilt knows what your internal project codenames look like. If you want a concrete example of how fast tool calls can become a data problem, this write-up on MCP PII data leakage is a good place to start.
5. Skills as a first-class object
This one has moved the fastest. A year ago, skills almost never came up. Now they are often the first item on the agenda. One CTO I spoke with recently had mandated a Git-based skills library two days before our call because three teams were scaffolding React projects three different ways. Another company had already built its own skills platform, complete with vector search and ratings, before it talked to a single vendor.
What people want from skills mirrors what they want from MCPs: a Git-based catalog so authorship runs through tools engineers already use, identity-based access policies tied to groups, and distribution that reaches whichever client the user is in. The same skill should land in Claude Desktop, Cursor, or a custom internal chat without three different deployment paths.
6. Audit logs that reach the SIEM
Security teams need to know who called what tool, with what arguments, and what came back. They need that data in Splunk or whatever system they already use, not trapped in a separate dashboard that somebody has to remember to open.
A few details come up every time. The auditor role has to be separate from platform admin because audit logs can contain the same sensitive data you were filtering on the way in. Export to S3-compatible storage needs field-level control. Audit data at rest needs encryption. Live streaming to observability backends is the obvious next step and more teams are asking for it, but scheduled export is still good enough for most teams today.
7. Deployment flexibility
The platform has to fit the customer’s infrastructure, not the other way around. Some financial services teams cannot use a hosted control plane at all. One team I work with has hundreds of regulations to satisfy, and a SaaS data plane is a non-starter. Other teams are comfortable with cloud-hosted as long as data residency is right. Most want the option to start one way and switch later.
On-prem has to be a real first-class path. Terraform, Helm, and the tools infrastructure teams already use matter. And vendors should be honest about prerequisites. If the product requires Kubernetes, say so up front. If you are evaluating what complete enterprise readiness looks like beyond deployment alone, this MCP enterprise architecture reference guide is a useful companion.
Core capabilities buyers now expect from an enterprise MCP platform.
That is the list
Seven things. It is not a list I could have written a year ago, but it makes a lot of sense today. The consistency is the signal. When buyers across industries start describing the same enterprise MCP platform requirements, it means the category is real and the market is maturing.
That is what has me excited about where Obot is headed.
If this resonates, I would love to compare notes. Book time with our team or find me on LinkedIn. I want to hear what requirements your team is seeing and what should be added to this list next.
