Tanzu Platform

Building an Enterprise MCP Server Marketplace with Tanzu Platform

The rise of agentic AI has fundamentally changed how we think about application integration. AI agents are no longer passive responders. They’re active participants that discover, invoke, and orchestrate tools to accomplish complex tasks. At the heart of this shift is the Model Context Protocol (MCP), an open standard that enables AI agents to interact with external tools and data sources through a natural language interface.

MCP servers provide a mechanism for application integration with remarkably loose coupling. Unlike traditional APIs with rigid contracts, MCP clients interact with servers through natural language, and there are no compile-time dependencies that break when tools evolve. This flexibility has sparked significant interest in organizations looking to empower their AI initiatives.

But this power comes with a challenge: In a large organization, how do you share MCP servers securely? How do you govern their access?

Teams across your enterprise are building valuable MCP servers connecting to internal databases, business systems, and proprietary data sources. Without a centralized approach, you end up with shadow deployments, inconsistent security practices, and no visibility into what tools exist or who’s using them.

What organizations need is an internal MCP server marketplace: a curated catalog where teams can discover, provision, and consume AI tools with enterprise-grade security and governance built in from the start.

With the 10.3 release of VMware Tanzu Platform, you can begin delivering this capability.

Turn any application into a marketplace service

Tanzu Platform service publisher, introduced in Tanzu Platform 10.3, allows you to take any application running on the platform and publish it to the Cloud Foundry Marketplace. Since an MCP server is just another application, this means you can publish AI tools as discoverable services for other teams and agents to consume.

This transforms the familiar Cloud Foundry marketplace (traditionally used for provisioning databases, message queues, and other infrastructure services) into a powerful distribution channel for AI capabilities. Teams can browse available tools, understand what each one offers, and provision access with a single command.

Cloud Foundry Marketplace with published MCP services
[Cloud Foundry Marketplace with published MCP services]

The experience feels natural to anyone who has used Cloud Foundry to provision data services. It’s the same patterns, the same commands, the same mental model now extended to AI tools.

Security and governance at the platform level

The ability to publish tools on a marketplace is only half the story. Platform teams need answers to critical questions:

  • Discovery How do agents find the tools they need?
  • Security – How do we ensure only authorized agents access sensitive data? How do we prevent agents from exceeding a user’s permissions?
  • Governance – How do we update or revoke access to tools centrally?

Tanzu Platform addresses these concerns through a combination of Spring Cloud Gateway and internal routing that provides defense in depth.

Network isolation by default

When an MCP server is published, its route is mapped to an internal domain (apps.internal). This means the MCP server is not directly accessible from outside the platform, or even from other applications within the platform. The service is invisible until explicitly exposed.

A Spring Cloud Gateway instance is created alongside the published service, and a network policy establishes that only this gateway can communicate with the MCP server. All external access must flow through the gateway.

[MCP Server network access protected by API Gateway]

Credential-based access control

When a consuming application binds to a published MCP server, it receives credentials through Cloud Foundry’s service binding mechanism. These credentials include the gateway URL and an API key that authenticates the caller. The credentials are injected into the application’s environment automatically—no manual configuration, no secrets in source control.

This means Tanzu Platform’s existing org and space security roles naturally extend to MCP server access. If a team doesn’t have access to create service instances in a space, they can’t provision access to the tools available there.

A practical example: The full lifecycle of an AI tool

Let’s walk through a concrete scenario. Team A has built an MCP server that provides tools for querying customer data. Team B is building an agentic AI application that could benefit from these tools. Here’s how the handoff works with Tanzu Platform.

Step 1: Build and publish the tool

Team A deploys their MCP server to Tanzu Platform like any other application. To make it available in the marketplace, they create a service definition YAML file that describes the offering: its name, description, and available plans.

yaml
name: customer-data-tools
description: MCP server providing customer lookup and analytics tools
plans:
  - name: standard
    description: Access to all customer data tools

Publishing is a single command:

bash
cf publish-service customer-data-tools -f service.yaml

[MCP server published as a service on the Cloud Foundry marketplace]

This pattern will feel immediately familiar to anyone who has worked with Cloud Foundry service brokers. The difference is that now any application can become a service. No custom broker code is required.

Step 2: Govern access to the tool

Published services are disabled by default. This is intentional, as it gives platform teams centralized control over what’s available and to whom.

A platform administrator reviews the published service and decides which organizations and spaces should have access:

bash
cf enable-service-access customer-data-tools -o product-team

This creates a clear approval workflow. New tools don’t automatically proliferate across the organization. They can be curated, enabled, and deprecated in a controlled manner.

Step 3: Consume the tool

Team B discovers customer-data-tools in the marketplace. They create a service instance and bind it to their agentic AI application:

bash
cf create-service customer-data-tools standard my-customer-tools
cf bind-service my-agent-app my-customer-tools

Behind the scenes, Tanzu Gateway provisions a route and API key. When Team B’s application restarts, it receives the gateway URL and credentials through the VCAP_SERVICES environment variable, the same mechanism used for database connections and other bound services.

[Creating a service binding to the MCP server offering]

Team B’s application can now invoke the MCP server’s tools. And because MCP uses natural language discovery, the application doesn’t need to be rebuilt if Team A adds new tools or modifies existing ones.

Step 4: Manage the tool lifecycle

Governance isn’t just about granting access. It’s about managing the full lifecycle, including deprecation and removal.

When Team A needs to sunset their MCP server, they can deprecate it to prevent new bindings while allowing existing consumers to continue operating:

bash
cf disable-service-access customer-data-tools

When it’s time to fully remove the service:

bash
cf unpublish-service customer-data-tools

This gives teams a controlled path for evolving their tool ecosystem without breaking existing integrations.

[Diagram of the flow of pushing, publishing, and consuming a MCP server as a service]

Scaling your tool ecosystem

A successful marketplace creates a virtuous cycle: as more tools become available, more teams build AI applications that consume them, which motivates more teams to publish tools. But this growth introduces a new challenge: how do agents efficiently select from dozens or hundreds of available tools?

Loading every available tool into an agent’s context is expensive (in tokens) and potentially confusing (the agent may struggle to choose appropriately). Spring AI addresses this with Dynamic Tool Discovery, which allows agents to search for relevant tools rather than loading all of them.

According to recent benchmarks, this approach achieves 34–64% token savings while improving tool selection accuracy. As your marketplace grows, this kind of intelligent tool routing becomes essential.

For more details, see Smart Tool Selection: Achieving 34–64% Token Savings with Spring AI’s Dynamic Tool Discovery.

What this means for your organization

With Tanzu Platform 10.3 and Tanzu Platform service publisher, you can build an enterprise MCP server marketplace that delivers on two critical outcomes:

For development teams: A curated catalog of AI tools that meet enterprise security and governance requirements. No more hunting for endpoints, begging for credentials, or worrying about whether a tool is sanctioned for production use. Discover what you need in the marketplace and provision it with a command.

For the organization: A collaborative ecosystem where any team can develop and publish new tools for others to consume. The platform handles the security, the access control, and the lifecycle management. Teams focus on building valuable capabilities.

[MCP server and tools are available to the application via the service binding]

Learn more

To explore how Tanzu Platform can empower your AI agents with tools and capabilities, read these additional resources: