> ## Documentation Index > Fetch the complete documentation index at: https://docs.budecosystem.com/llms.txt > Use this file to discover all available pages before exploring further. # MCP Foundry Concepts > Learn how MCP Foundry models capabilities, servers, access, and federation. MCP Foundry is built around a simple principle: capabilities are managed once, then exposed through curated MCP endpoints. This page explains the concepts needed to design that model safely. ## Capability catalog and virtual servers The catalog contains independently managed tools, resources, prompts, and skills. A virtual server is the composition boundary: it selects which catalog items a particular MCP endpoint exposes. This lets a platform share a common catalog without making every capability available to every agent. ```mermaid theme={null} flowchart TB subgraph Catalog T[Tools] R[Resources] P[Prompts] S[Skills] M[Connected MCP servers] end T --> V[Virtual server] R --> V P --> V S --> V M --> V V --> C[Authorized MCP clients] ``` ### Tools A tool describes an operation an agent can request. For internally managed HTTP integrations, the definition includes the endpoint, request configuration, authentication, an argument schema, and visibility. The schema is an important control: it documents the action and constrains valid inputs before the backend is called. Image ### Resources Resources make information available as MCP-readable context. They may point to a URL or contain inline text. Use tags, ownership, resource type, and visibility to make resources discoverable and maintainable. Attach a resource to a virtual server before expecting an agent connected to that server to access it. Image ### Prompts Prompts are named, reusable instruction templates. They accept declared arguments and can use Jinja-style templating to adapt to different inputs. When a prompt is attached to a virtual server, MCP clients can discover it as a named capability instead of embedding the instruction in every client application. Image ### Skills A skill is a portable package of markdown instructions and associated tools. It describes an outcome-oriented procedure: which tools to use, constraints to follow, checks to perform, and how to format a response. Skills make organizational operating knowledge reusable across agents and supported gateways. Image ## MCP servers and federation An MCP server is a provider of MCP capabilities. MCP Foundry can connect to pre-integrated registry entries, hosted endpoints, self-hosted services, and server packages that need a network wrapper. Connected capabilities can be incorporated into the catalog and composed into virtual servers. Image Federation extends this model across gateways. Consumers see a consistent catalog while the platform routes an invocation to the capability's owning server or gateway. ```mermaid theme={null} flowchart LR A[Agent] --> B[Local virtual server] B --> C{Capability location} C -->|Local| D[Internal API tool] C -->|Connected| E[External MCP server] C -->|Federated| F[Peer MCP gateway] F --> G[Remote MCP capability] ``` ## Access and governance Use several complementary boundaries rather than relying on a single setting: | Control | What it governs | | -------------------------- | ----------------------------------------------------------------------------------------------- | | Visibility | Whether an item is private, internal, or public according to the deployment policy. | | Teams and ownership | Who manages an item and which organizational boundary it belongs to. | | Virtual-server composition | Which items are presented from a specific MCP endpoint. | | Authentication | How clients and backend API calls establish identity. | | API tokens | Programmatic client access, typically scoped and managed independently of interactive sessions. | | Roots | Directories that file-capable server workloads are permitted to access. | | Logs and metrics | Evidence for investigation, monitoring, and continuous improvement. | > **Important:** Visibility does not replace least-privilege backend credentials. Give each tool only the API permissions required for its intended operation, and expose the tool only through the necessary virtual servers. ## Lifecycle A healthy capability lifecycle is iterative: define, validate, publish, observe, and refine. Generation jobs follow the same principle—review generated tools before associating them with a production virtual server. ```mermaid theme={null} flowchart LR A[Define or import] --> B[Validate schema and authentication] B --> C[Assign owner, tags, and visibility] C --> D[Attach to virtual server] D --> E[Test with Playground] E --> F[Monitor logs, errors, and latency] F --> G[Update, restrict, or retire] G --> A ``` ## Design recommendations * Prefer several small, purpose-specific virtual servers over one broad endpoint. * Keep tool descriptions action-oriented and schemas explicit so agents can choose tools correctly. * Treat prompts and skills as governed assets: give them owners, tags, and a review path. * Start generated tools in a restricted environment and validate endpoint, authentication, argument mapping, and error behavior. * Use teams and server composition to minimize accidental cross-department exposure.