Managing the MCP Server Service

The Model Context Protocol (MCP) is an open standard designed to let AI assistants and agents securely interact with enterprise systems through natural language.

The Model Context Protocol (MCP) in CTERA lets AI assistants and agents securely interact with the CTERA platform as a framework for defining and managing a variety of context-based configurations across the platform. This feature facilitates dynamic policy enforcement and adaptive user experiences by leveraging contextual data to tailor services, enhancing both security and efficiency.

MCP provides a structured, permission-aware interface that allows models to:

• Query systems like file storage or analytics.
• Perform user-authorized actions.
• Maintain session context across tools and tasks

MCP standardizes the interaction layer, making secure, intelligent automation scalable without the need for custom integrations for every system. SDKs help developers build integrations, whereas MCP is the integration layer itself: a shared language that AI models use to communicate with to enterprise tools. In other words, it’s plug-and-play for AI.

Embedding MCP support directly into the CTERA Portal enables LLMs, whether commercial tools like Claude and Cursor, or internally developed agents, to securely:

• Summarize file uploads in a shared folder.
• Retrieve document versions based on content.
• Generate and distribute a public or internal file link without a graphical user interface (GUI).
• Manage files using natural language instead of scripts or dashboards.

The CTERA MCP Server provides a natural language ability to perform actions that can be done using the CTERA SDK. The natural language used to talk to the agent that uses the MCP Server is internally mapped to an API in the CTERA SDK.

These tasks are executed securely, enforced by encryption, permissions, and audit logging. There’s no need to copy data to external AI systems or learn new APIs.

What Agents Can Be Used with the CTERA MCP Server

Agents that support the MCP protocol can be used. The following agents support the MCP protocol and have been tested to be used with the CTERA MCP Server:

• OpenAI agents
• Claude
• Cursor

In addition, internal agents and other publicly available agents that support the MCP protocol can also be used. CTERA has certified Claude and Cursor are certified for use with the CTERA MCP Server.

The agent must be configured for the user that is using the agent and with a connection to the CTERA MCP Server. Agents are authenticated using OAuth 2.0 to ensure that third-party applications get limited, delegated access to a user's resources without exposing the user's password.

Requirements

The following requirements are necessary to use the CTERA MCP Server:

• A second NIC. You require two NICs for each portal server. In order not to compromise security, the internal NIC must not be accessible from the external network.

  Both NICs can be on the same VLAN but the internal NIC must have a different IP than the external NIC. CTERA strongly recommends a separate VLAN or proper firewall rules.
  By default, the NICs are eth0 for the external interface and eth1 for the internal interface. If different names are used, /etc/ctera/portal.cfg on each server must be edited to reflect the different names, where:
  CTERA_EXTERNAL_INTERFACE=<external_iface_name>
  CTERA_INTERNAL_INTERFACE=<internal_iface_name>

  Note

  Upgrading a portal automatically assigns the correct name to CTERA_INTERNAL_INTERFACE. If the external NIC is not eth0, /etc/ctera/portal.cfg must be edited on each server with CTERA_EXTERNAL_INTERFACE=<external_iface_name>.

  In a multi-datacenter (multi-DC) architecture with separate VLANs, the internal IPs of all portal servers must be routable to each other across the datacenters.

  Warning

  If the current network configuration uses eth0 for the portal network and eth1 is free, then the upgrade can proceed. If, however, eth0 or eth1 are not available, you must contact CTERA Support, as changes need to be made to portal.cfg before you can continue.

  For ESXi:

  1. For every server, right-click the portal VM in the navigation page and choose Edit Settings.
  2. Click ADD NEW DEVICE > Network Adapter.
     A new network is added to the list of networks.
  3. Click OK.
  4. Run the following commands after adding the internal network interface to remove the default route (adapter name: eth1):

     export ETHNAME=`nmcli -t -f NAME,DEVICE connection show | grep
     ":eth1" | cut -d: -f1`
     nmcli connection modify "$ETHNAME" ipv4.ignore-auto-routes yes
     nmcli connection modify "$ETHNAME" ipv4.gateway ""
     nmcli connection down "$ETHNAME"
     nmcli connection up "$ETHNAME"
     

• An identity provider (IdP) such as Microsoft Entra ID, Okta, AuthO.

• OpenID Connect (OIDC)

• Internet access

Restrictions

The CTERA MCP Server provides a natural language ability to perform any actions that can be done using the CTERA SDK for end user tasks, but not for administrator tasks such as creating a user. The natutal language used to talk to the MCP Server is internally mapped to an API in the CTERA SDK.