Short answer
A custom MCP server can be the right choice for a narrow prototype. A Gateway is better when tool access needs repeatable governance.
A custom MCP server usually solves one integration at a time. That can be fast, but the team still has to design auth, credentials, publication state, validation, rate limits, logging, and operational visibility.
Swagger to MCP Gateway packages those concerns into a reusable publishing layer for OpenAPI APIs and database scopes.
The honest decision is not custom versus gateway in the abstract. The decision is whether the work is a small adapter with limited risk, or a production surface where many clients, teams, sources, and customers need the same controls repeatedly.
Decision factors
Choose based on operational responsibility, not only first-week implementation speed.
| Question | Custom MCP server is reasonable when... | Gateway model is stronger when... |
|---|---|---|
| How many sources? | One local script or one stable internal API. | Multiple OpenAPI APIs, database scopes, tenants, or teams. |
| Who owns credentials? | A trusted developer or single controlled environment. | Credentials must stay server-side, rotate cleanly, and never land in client config. |
| How risky are the tools? | Read-only or low-impact actions with simple validation. | Tools touch customer data, production APIs, database scopes, or operational workflows. |
| How much observability is needed? | Basic logs are enough. | Usage, latency, failures, redaction, quota pressure, and audit events matter. |
| How often will the catalog change? | Rarely, and clients can be updated manually. | Tools need to be hidden, republished, or tuned without editing every client. |
Comparison
The difference is less about the MCP protocol and more about who owns production controls.
| Area | Custom MCP server | Gateway model |
|---|---|---|
| Source setup | One server or adapter per source. | One publishing model for OpenAPI integrations and PostgreSQL or SQL Server scopes. |
| Tool lifecycle | Tool names, descriptions, schemas, and visibility are maintained in code. | Tools are generated from source metadata and curated before publication. |
| Credentials | Often handled in local config, environment variables, or custom code. | Upstream API credentials and database connection strings stay server-side in the Gateway. |
| Validation | Implemented separately per server and can drift between teams. | OpenAPI and database-specific validation live in the Gateway path before execution. |
| Database safety | Requires custom schema filtering, SQL validation, row limits, audit redaction, and scope checks. | Schema tools are metadata-only; executor tools validate scope, table, column, relationship, and policy rules. |
| Agent testing | Usually tested after a client is configured. | Gateway Chat can test tool choice and arguments before external rollout. |
| Observability | Built per server if needed. | Usage dashboards, redacted logs, limits, latency, and audit events are part of the Gateway surface. |
| Change control | Redeploy or update clients when behavior changes. | Hide tools, update descriptions, unpublish scopes, or rotate tokens without changing every client. |
Security boundary
The Gateway remains the enforcement layer even when an LLM proposes a tool call.
AI clients and orchestration frameworks may request tool calls, but the Gateway checks source ownership, publication state, limits, redaction policy, and source-specific validation before execution.
That separation matters for B2B systems because the model should not become the trust boundary.
When a custom MCP server still fits
A gateway should not become an excuse to avoid custom engineering where custom engineering is genuinely needed.
- The tool wraps a local developer workflow, file operation, or test script.
- The integration has domain-specific behavior that cannot be represented well by OpenAPI operations or database scopes.
- The server is a short-lived prototype for one team and one trusted environment.
- The tool needs a specialized runtime, streaming behavior, or interactive protocol that the Gateway source model does not support.
- The team already has a reviewed server framework with auth, validation, redaction, limits, and observability built in.
A practical migration path
Teams do not have to choose one model forever.
- Start custom when the shape of the workflow is still unknown.
- Move stable OpenAPI-backed actions into a Gateway-published surface once the tool contract is clear.
- Move database context into database scopes instead of giving custom servers broad SQL access.
- Keep genuinely specialized tools custom, but place shared auth, logging, and token practices behind the same operational review.
- Use Gateway Chat or an equivalent test harness to verify tool choice before exposing the surface to more clients.
Common questions
Is a Gateway required to use MCP?
No. MCP can be implemented directly. A Gateway is useful when teams need repeatable controls across sources, accounts, credentials, logs, and limits.
Can a Gateway and custom MCP servers coexist?
Yes. Teams can keep specialized custom servers where needed and use the Gateway for OpenAPI APIs or database scopes that benefit from centralized publishing and governance.
Who should prefer a Gateway?
Platform teams, B2B SaaS teams, and organizations exposing real systems to AI clients should prefer a Gateway when security and operations matter.
Can I start with a custom MCP server and move to a Gateway later?
Yes. A practical path is to prototype custom, then move stable OpenAPI-backed actions or database scopes into a Gateway once the tool contract and security needs are clear.
Does a Gateway remove the need for custom MCP servers?
No. Specialized tools can stay custom. The Gateway is strongest for repeated publishing, credential handling, validation, logging, and governance around OpenAPI APIs and database scopes.