MCP

MCP servers connect the agent to the systems your organization already uses. They use the Model Context Protocol (MCP) to give the agent the ability to work across platforms that are already part of your workflow, making Infracodebase a single pane of glass for infrastructure operations.

For example, the Terraform MCP server lets the agent connect to Terraform Cloud or Enterprise, look up public modules, check provider versions, and pull configuration details. The AWS MCP server lets it query your cloud resources, check configurations, and gather context. Each server extends what the agent can see and do without leaving the platform.

Adding servers from the registry

Browse available MCP servers at the MCP Registry. When you find one you need, add it to your enterprise and configure it with your credentials.

Each MCP server requires authentication. When you configure a server, you provide credentials like API tokens, access keys, or service account details. These are stored as encrypted secrets.

Configuring credentials

The credentials you provide determine what the agent can do within each connected platform. The agent's abilities are limited by the permissions of the token or service account you configure.

Scope your credentials appropriately. Use service accounts or tokens with the minimum permissions needed for your use case. If you only need the agent to read infrastructure state, don't give it write access. This limits the blast radius and keeps your integration secure. Review the permissions of each token you provide and follow the principle of least privilege.

Granular tool control

Each MCP server exposes a set of individual tools. You get very granular control over which tools are available to your team.

Server-level toggle to enable or disable an entire MCP server and all its tools
Individual tool toggles to disable specific tools within a server while keeping the rest active

For example, if an MCP server provides 10 tools but 3 of them are not appropriate for your organization, you can disable just those 3. The agent will have access to the remaining 7.

Connection status

The MCP settings page shows the status of each configured server. Servers can be connected, missing credentials, disabled, or in a failed state. You can test connections after configuring credentials to verify everything is working.

Runtime isolation

Each agent session gets its own dedicated MCP server processes. When a user starts a session, the platform spawns fresh instances of the configured MCP servers as isolated child processes with their own credentials. These processes are not shared or pooled between users or sessions. When the session ends, the processes are terminated.

This means one user's connections are completely isolated from another's. There is no cross-session access to credentials or state, even when multiple users are connected to the same MCP server type.

Enterprise vs. workspace

Enterprise MCP servers are available across all workspaces by default. In each workspace, you select which of the configured servers and their tools to use for your specific project. From the workspace settings, navigate to the MCP section to see the available servers and toggle individual tools on or off.

Adding your own MCP server

In addition to the servers available in the registry, you can connect the agent to your own MCP servers. This is useful when your organization has built custom tooling, internal APIs, or proprietary systems that you want the agent to interact with.

From the MCP settings page, click Add MCP Server. You will be prompted to provide a JSON configuration block that defines the server connection. Paste in your configuration and the platform will register the server and make its tools available to the agent.

Here is an example configuration for a custom MCP server:

{
  "name": "internal-deploy",
  "description": "Internal deployment pipeline API",
  "transport": "sse",
  "url": "https://deploy-api.internal.yourcompany.com/mcp",
  "headers": {
    "Authorization": "Bearer ${DEPLOY_API_TOKEN}"
  }
}

The name field identifies the server in your list. The description helps your team understand what the server connects to. The transport field specifies the connection protocol. The url is the endpoint where your MCP server is running. Any credentials referenced in the configuration, like ${DEPLOY_API_TOKEN} in the example above, should be stored as secrets so they are encrypted and not exposed in the configuration itself.

Once added, your custom MCP server behaves like any other server in the platform. You get the same granular tool control, connection status monitoring, and runtime isolation. You can enable or disable individual tools, and each agent session gets its own isolated connection. The server and its tools appear in the MCP section of your settings and can be enabled per workspace.

Coming soon

We are working on support for connecting to MCP servers running behind your own VPC or virtual network. This will let the agent reach data and services inside your private infrastructure without exposing them to the public internet.