Introduction to MCP Foundry

Understand the enterprise control plane for creating, federating, and governing MCP capabilities.

Overview

MCP Foundry is the control plane for making enterprise systems available to AI agents through the Model Context Protocol (MCP). It provides one governed place to create capabilities from internal APIs, connect existing MCP servers, package reusable instructions, and publish only the capabilities each client is allowed to use.

An agent becomes useful when it can safely retrieve context and take action in the systems where work happens. MCP Foundry connects that agent layer to enterprise APIs, knowledge, and operational policies without requiring every agent to manage a different integration or security model.

What you can do

• Create tools that expose internal HTTP APIs as MCP-callable functions, with input schemas, headers, authentication, tags, and visibility controls.
• Generate tools at scale from OpenAPI specifications, API documentation URLs, or Postman collections instead of defining each endpoint manually.
• Add resources for agent-readable organizational knowledge, either from a URL or inline content.
• Manage prompts as reusable, parameterized templates that MCP clients can discover and invoke.
• Build portable skills that combine markdown instructions with selected tools and can be reused across agents and supported gateways.
• Federate MCP servers by connecting hosted, self-hosted, registry, or deployable MCP servers into a managed catalog.
• Publish virtual servers that present a purpose-built combination of tools, resources, prompts, and skills to MCP clients.
• Govern and operate the estate with teams, API tokens, roots, logs, dashboards, and server-level visibility controls.

The operating model

MCP Foundry separates the capabilities you manage from the endpoints your agents use. First, platform teams register or generate reusable building blocks. Then they compose those building blocks into virtual servers. Finally, agents connect to the published server over an MCP-compatible transport and receive only the exposed catalog.

Core building blocks

Building block	Purpose	Typical example
Tool	A callable operation backed by an API or connected MCP server.	Create a support ticket or look up a customer.
Resource	Context an agent can read.	A policy page, runbook, or inline knowledge article.
Prompt	A reusable template with defined arguments.	Produce a compliant customer-response draft.
Skill	Portable markdown instructions associated with tools.	Triage and resolve a support request consistently.
MCP server	A connected source of MCP capabilities.	A self-hosted server or a registry integration.
Virtual server	A curated MCP endpoint that exposes selected building blocks.	A production support-assistant server.

A typical enterprise workflow

1. A platform or application team adds an internal API as a tool, or generates tools from its API definition.
2. A knowledge owner adds policy documents or inline content as resources.
3. Subject-matter experts create prompts and skills that specify how an agent should use the available capabilities.
4. An administrator creates a virtual server, attaches the approved capabilities, and configures access and visibility.
5. An MCP client connects to the virtual server, discovers its catalog, and invokes the allowed tools, resources, prompts, or skills.
6. Operators monitor requests, latency, failures, and audit activity, then adjust the configuration as requirements change.

Next steps

• Start with Quickstart to publish a first governed endpoint.
• Read MCP Foundry concepts before designing a larger catalog.
• Use Creating your first server for the end-to-end composition workflow.