Agent infrastructure
Platform integration
MCPs library: what the public MCP server directories actually contain, why they break for SaaS companies, and what an internal MCP catalogue must do at scale.
The phrase "MCPs library" gets searched by two very different people. One is an engineer trying to find an existing MCP server for a SaaS product they use — Linear, Notion, GitHub — so they can wire it into Claude or Cursor without writing anything. The other is a platform lead at an established SaaS company who's started to realise they will, one way or another, end up running an internal catalogue of MCP servers for their own products. Both groups type the same query. They want very different things.
This piece is for both, but it argues something specific: the public MCP server directories are useful for discovery and almost useless for production. The real library that matters — the one your agent project depends on — is the internal catalogue of servers that wrap your own products, versioned alongside the products they expose. Most teams haven't built that yet, and that's where their agent work is stalling.
We'll cover what the public libraries actually contain, where they break, what a production-grade internal catalogue needs to do, how teams are managing MCP servers at scale, and what the realistic build path looks like.
When someone searches "mcps library" or "mcp server library", they usually land on one of four places. There's the official Model Context Protocol servers repository on GitHub, now stewarded by the MCP Steering Group under the Linux Foundation's Agentic AI Foundation (the protocol was originally created by Anthropic and donated to the foundation in December 2025). There's Smithery, which positions itself as a registry and one-click installer. There's mcp.so, an aggregator listing tens of thousands of community-built servers. And there's PulseMCP, which functions more like a directory with categorisation.
Each of these is a real catalogue. Each contains thousands to tens of thousands of entries. And each is, in practice, a discovery surface — not a runtime, not a maintenance contract, not a governance layer. They tell you a server exists. They don't tell you whether it works against the current version of the product it wraps, whether the maintainer is still active, or whether the tool definitions match what the underlying API actually does today.
This isn't a criticism of the directories. It's a description of what they are. A library of MCP servers is the agent equivalent of npm: a list of things you can install. Whether any specific entry is safe to depend on is a separate question, and one most of these catalogues don't try to answer.
A typical browse through one of these libraries surfaces three rough categories of server:
If you're building an agent for personal or internal use and you need to read a Notion database or post to Slack, this is genuinely useful. You find a server, install it, point it at a token, and you're running. For that use case the public library does its job.
The situation flips when you're the SaaS company. Your customers want to build agents that act on your product. You're now thinking about whether a third party should be listed in a public library wrapping your API, or whether you should publish your own, or whether your customers should be building their own. And then you're thinking about what happens when your API changes next quarter.
Three problems surface immediately.
The catalogues don't enforce a contract with the underlying product. A community-built MCP server for your product is, from your perspective, an uncontrolled client of your API. It will break silently when you ship a breaking change. Your customers will blame you, not the server author. You have no way to deprecate it, no way to push an update, no way to even know who's using it.
The surface gap is structural, not editorial. Your API exposes a fraction of what your product can do. We've written about why — APIs were built for a different era, and the surface they expose hasn't kept up with what the UI delivers. A community MCP server can only wrap what your API exposes. So the public library entry for your product is, by construction, a thin shadow of what an agent actually needs.
Maintenance has no SDLC. A server in a public catalogue isn't versioned alongside your product. There's no CI step that says "the new release broke three tools". There's no test suite that runs against the live API. The server drifts from the product until someone notices, usually because an agent failed in front of a customer.
None of this is the catalogue's fault. Public libraries are inherently discovery layers. They can't enforce contracts they don't own. But it means the answer to "is there an MCP server for our product?" is almost never the answer you actually need, which is "is there a server we control, that stays current, and that exposes everything our agents need to reach?"
The library that matters for a SaaS company is the internal one. Call it an MCP tools catalogue, a tool registry, or just "the place our agents look for what they can do" — the name matters less than the shape. Here's what it has to handle that a public directory doesn't.
The pattern isn't subtle: the public library is a marketplace, the internal catalogue is infrastructure. They optimise for different things. A SaaS company that treats the public listing as sufficient is one breaking change away from a customer-visible failure that no one on their team will be able to diagnose.
We've gone deeper on the architectural shape of this in our practical setup and architecture guide for MCP servers. The short version: the catalogue isn't a static list. It's a runtime-backed registry, with each entry tied to a specific version of a server, exposed under specific auth conditions, observed in production, and maintained through CI.
Reducing it further, an internal MCP catalogue has to hold four things for every tool it lists:
Miss any of these and you don't have a catalogue. You have a list of things that used to work.
For a single MCP server wrapping a single product, the engineering team can hand-maintain it. Most teams start there. The pain begins around server number three.
A typical established SaaS company has somewhere between four and twenty products in its portfolio, depending on how you count. Each product has its own API surface, its own release cadence, its own auth model. If the answer to "how do we expose this to agents?" is "build an MCP server per product", you're looking at four to twenty servers, each of which has to be:
This is the cost we've documented in our piece on the hidden cost of bespoke agent connectors. The work compounds. Each new product doesn't add one server's worth of work — it adds one server's worth of build plus a fractional increase in maintenance load across the existing ones, because every shared component, every auth library, every retry pattern, has to be kept consistent.
This is where teams hit a fork. The two unfundable answers are: rewrite all the APIs so the existing surface is rich enough that one good wrapper covers it, or commit to a permanent bespoke-connector team. The first takes years. The second never gets leverage from one product to the next.
The third answer is to generate the catalogue from the products themselves. If a server can be generated from the existing codebase, regenerated when the product changes, validated against the live API in CI, and run with a managed runtime, the per-product cost drops from "a team for a quarter" to "a build step". That's the only path we've seen that scales across a portfolio.
A reasonable question at this point: don't MCP gateways handle this? The answer is no, and the distinction is worth being clear about.
MCP gateways — Portkey, Lunar.dev, MintMCP, and others — sit between agents and MCP servers. They handle routing, auth proxying, rate limiting, and observability across servers that already exist. They're a governance layer for a population of servers.
That's a real and useful layer. It is not the same as having servers in the first place. A gateway in front of an empty catalogue solves nothing. A gateway in front of a catalogue of stale, hand-maintained servers governs the staleness more cleanly but doesn't fix it.
For a SaaS company whose actual problem is "our APIs don't expose what our agents need, and we have no servers wrapping our products", the gateway is the wrong layer to invest in first. The catalogue — the generation, the maintenance, the runtime — has to come first. Then governance makes sense on top of it.
We've gone deeper on this distinction in our piece on where the agent stack actually breaks for SaaS teams.
Pontil is a Tools-as-a-Service platform. We generate MCP-compatible tools from the codebase of your existing products, run them on a managed runtime that executes as the authenticated user, and keep them current as the underlying products change. The internal catalogue described above is what we produce — not a public directory of community servers, but a generated, versioned, observed catalogue of tools that match what your product actually does today.
We operate on systems you own. Your APIs stay the contract. Your CI, your tests, and your observability all continue to work. The maintenance is automated, so the catalogue doesn't drift the moment your team's attention moves elsewhere. And because the runtime honours the authenticated user's identity, the permissions and audit story that already works in your product keeps working when agents act through it.
If you're at the point where you've found the public MCP libraries and realised they don't solve the problem you actually have, a demo is the fastest way to see what the internal version looks like in practice.
The public MCP libraries aren't going anywhere, and they shouldn't. For discovery — for finding a server someone else built that you can wire into your own agent for your own use — they work. They're the package-manager layer of the agent ecosystem, and that layer has a real job.
What they're not is the answer to "how do we, as a SaaS company, make our products accessible to agents". That answer has always been internal, has always required versioning against the product, has always needed a runtime and a maintenance story. The phrase "MCPs library" describes both things in the same words, and the conflation is part of why so many SaaS teams have spent a quarter looking at public catalogues before realising they're shopping in the wrong store.
The useful question isn't "which MCP library should we list our server in?". It's "what does our internal catalogue need to do, who builds it, and how does it stay current?". Answer that and the public listing question becomes trivial. Skip it and no amount of public-directory presence will close the gap your agent project is stuck on.
Stay up to date on the ever changing agentic landscape.
