> ## Documentation Index > Fetch the complete documentation index at: https://docs.meibel.ai/llms.txt > Use this file to discover all available pages before exploring further. # Integrations > How Meibel connects to external systems, and how agents use those connections as tools ## Overview An integration is a connection between Meibel and an external system. An organization connects a system once, and projects and agents across the organization then build on that single connection. The integration holds everything the platform needs to reach the system: where it lives, how to authenticate to it, and which of its capabilities each project may use. Integrations come in two kinds. **MCP integrations** connect to servers that implement the Model Context Protocol and give agents new tools to call while they work. **Data integrations** connect to systems that hold data, such as file storage and databases, so their content can flow directly into datasources. ## MCP integrations The Model Context Protocol (MCP) is an open standard for exposing tools to AI applications. An MCP server publishes a set of tools, each with a name, a description, and a schema for its parameters, and a client such as an agent can discover and call those tools. Many services offer MCP servers, which lets an agent perform a wide range of external activities, including searching an issue tracker, reading a knowledge base, or querying a business system, without custom code. An MCP integration connects Meibel to one remote MCP server over HTTPS. The integration catalog lists ready-made entries for common services, such as GitHub, Atlassian, and Notion, with the server's address and sign-in method already filled in. The available entries change as services publish and retire their servers. For any server the catalog does not list, a custom MCP server integration connects to an arbitrary server URL. Custom servers let an organization bring its own MCP services into Meibel, including servers it builds and hosts itself. Once connected, an integration keeps a list of the tools its server offers. When the server adds or changes tools, the list picks up those changes after an organization owner or admin refreshes it from the integration's page in the dashboard. Owners and admins also decide which of the listed tools each project may use. ## Connection and credentials Most MCP servers require authentication. An integration supports the methods MCP servers commonly use: * **No authentication**, for public servers. * **Bearer token**, such as a personal access token or API key sent as a token. * **Username and password**, sent as basic authentication. * **Custom headers**, for servers that expect a key in a specific header. * **OAuth 2.0**, most often a sign-in where a person signs in to the service in a browser window and grants Meibel access. For a custom server, the Meibel platform can inspect the server URL and detect which sign-in method it expects, so the connection form starts from the right choice. Meibel stores credentials encrypted and never displays them again after they are saved. They can be replaced but not read back. When an agent calls a tool, the platform attaches the credentials to the request on the agent's behalf, so neither the agent nor its underlying model ever sees them. An integration that uses OAuth depends on the sign-in staying valid. If a sign-in is interrupted or a token expires, the integration reports that it needs attention, and reconnecting it repeats the sign-in without recreating the integration or changing the agents that use it. ## Configurations and scope One connection to a server often needs to serve several purposes. A support team might need only the read tools of an issue tracker, while an engineering team needs the tools that create and update issues. Rather than connecting the same server multiple times, an integration holds one or more **configurations**. Each configuration sets the **scope** of what it allows, meaning which of the server's tools are available through it, and which projects may use it. When an integration connects, the platform asks the server for its tools and stores the list. A server can add, change, or remove tools after it is connected, so the stored list can be refreshed to pick up those changes. That list is what an integration's configurations choose from. Every integration starts with a **default configuration** that is available to every project in the organization. Its scope either allows all of the server's tools, including tools the server adds later, or allows a specific set chosen from the stored list. Additional configurations can narrow the scope further and be granted to particular projects, so the projects that need a restricted toolset receive one while the default serves everyone else. The connection and its credentials belong to the integration, and every configuration shares them. A configuration only decides what is exposed through that shared connection. ## Organizations, projects, and roles Integrations belong to an organization and are shared across its projects. Organization owners and admins create integrations, manage their credentials and configurations, and decide which projects can use each configuration. Other members can see the organization's integrations and attach the ones available to their project to agents, but cannot change them. This split keeps credentials and access decisions with the people responsible for them, while letting each project's agent builders work with the tools that are appropriate for their use. ## How agents use MCP integrations An agent uses an MCP integration through one of the integration's configurations. In the dashboard, the integration is added to the agent's tools and a configuration is selected for it. Through the API, the agent's tool list names the integration and configuration directly. Either way, the agent gains an **MCP server entry**, and the entry's name is how the rest of the platform, including execution policies, refers to that server's tools. When an agent session starts, the platform reads the selected configuration, retrieves the server's current tools, and keeps the ones the configuration's scope allows. Each tool reaches the agent with the description and parameter schema the server publishes, so the agent's underlying model sees the tool as the server defines it. The tool list is fixed for the life of the session. A refresh of the server's tools or a change to the configuration applies to sessions started afterward. When the agent calls one of these tools, the request goes through Meibel to the server, and the result returns to the agent like the result of any other tool. Tool results can be cited as sources in the agent's response, alongside documents retrieved from datasources. ## Integrations and execution policies An integration's configuration and an execution policy both shape what an agent can do with a server's tools, and they work at different levels. The configuration decides which tools exist at all for any agent given that configuration, in every session. An [execution policy](/concepts/execution-policies) then constrains those tools for a particular agent or session. Within a policy, each MCP server entry has its own section in `mcp_servers`, keyed by the entry's name. A policy can disable individual tools, fix a parameter to a single value, or limit the values a parameter accepts, such as capping a result count or pinning a project key. A server-wide rule under `global` applies to every tool the server exposes, including tools added after the policy was written. Because policies only narrow access, a policy cannot restore a tool that the configuration leaves out. The platform enforces these constraints outside the agent's underlying model. A tool call that violates the policy is rejected before it reaches the server. See [Tool constraints](/concepts/execution-policies#tool-constraints) for the full syntax. ## Related concepts The agents that call an integration's tools, and how their configuration fits together. The platform-enforced constraints that narrow which tools a session can use and what values they accept. The containers that hold an agent's data, and the destination for data integrations. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.