Pi - the multi-purpose, built-in AI Agent in Planhat OS - already comes with a large set of built-in tools for working with your Planhat data: searching Companies, reading Conversations, creating Tasks, writing notes and so on. A lot of the context your team relies on, however, lives outside Planhat: customer updates in Slack channels, account plans and QBR decks in Google Drive, and similar.

MCP Plugins extend Pi with tools from those external applications, via a library of 20+ pre-configured Plugins - Slack, Google Drive and GitHub are the featured starting points. Once an MCP Plugin is set up, a CSM can ask Pi things like "Summarize the latest updates in the Slack channel for Acme" or "Find the account plan for Acme in Google Drive and pull out the agreed next steps", and Pi will call the external tool, read the result, and continue working with it inside the Session - for example, by saving the summary as a note on the Company.

This article is the technical deep dive for the people who set this up for their organization. It covers the concepts you need to make good decisions (in particular which connection type to use), the step-by-step setup in Planhat and in the external application, and how to manage the connections afterwards.

MCP (Model Context Protocol) is an open standard that defines how an AI assistant can discover and call "tools" exposed by another application. An application that exposes tools is an MCP server; the AI application that calls those tools is an MCP host (or client). The tools themselves are small, well-described operations - for example "search messages", "list files in a folder" or "read a document".

In the context of MCP Plugins, Pi is the MCP host and the external application (Slack, Google Drive, etc.) is the MCP server. When a User asks Pi something that requires external data, Pi selects the appropriate tool based on the tool descriptions and the User's request, calls it with the User's authorization, and uses the result in its reply.

Planhat participates in MCP in two directions, and it is worth being clear about which one you are setting up:

Both can be used at the same time. This article only covers MCP Plugins. For Planhat's MCP server, see our OAuth Clients overview and the connection guides for Claude and ChatGPT.

When you create an MCP Plugin, you choose how Planhat should authenticate with the external application. This is the most important decision in the setup, because it determines whose data Pi can see and how the activity appears on the external application's side.

Multiple layers combine to determine what Pi can actually do through an MCP Plugin. It is useful to understand them, because "Pi can't find the file" is usually explained by one of these layers rather than by the Plugin itself.

Now you are familiar with the background context of MCP Plugins, next in this article we'll go through how you - as a Planhat Admin - set up MCP Plugins in Planhat.

Next, we'll go through the actual setup steps.

If the application you want to connect to is not in the Plugin library - e.g. your own internal MCP server - you can add it as a custom MCP connection. The flow is similar compared to a template, except that you supply the server details yourself:

The steps in this stage start outside of Planhat, in the external application's developer or admin console. For OAuth Plugins (most templates), the main principles are the same for every application: create an OAuth app, register Planhat's Callback URL as an allowed redirect URL, and copy the Client ID and Client Secret and paste them into Planhat. For a Plugin that uses an API token or username/password, the equivalent to this stage is simply generating the token or service credentials in the external application.

Below, we will walk through Slack, as the most common example.

With an Individual connection, each User will need to connect their own account once - see our separate guide for Users.

The screenshot below is an example of what another User who is an Admin (has the "Admin Access" workflow permission) would see; general non-Admin Users will only see their own connection here.

Click the image to view it enlarged

With a Central connection, Users have nothing to connect - instead, you grant access as part of the MCP Plugin, to the Users or Roles who should be able to use it, and then they will see it as available in their MCP Plugins view. Either you can grant access as part of the original MCP Plugin setup form as we discussed earlier, or you can "Add access" to an existing MCP Plugin, as shown in the example screenshot below.

The next step for you as an Admin - whether your MCP Plugin is an Individual or Central connection - is to communicate to your Users, i.e. your colleagues in your Planhat tenant.

The MCP Plugins Tool lists every Plugin configured in your tenant. As an Admin (with the "Admin Access" workflow permission in your Role), you can see each Plugin's connection type, whether it is enabled, and (for Individual connections) your own connection status. General Users see only the Plugins available to them and their own connection status.

Click the image to view it enlarged

Click the image to view it enlarged

If a Client Secret is compromised or your security policy requires periodic rotation, you can generate a new secret in the external application (Slack: Basic Information → App Credentials → "Regenerate"; Google: Credentials → the OAuth client → "Reset secret"), and then paste the new secret into the MCP Plugin configuration in Planhat and save. Depending on the application, existing User authorizations may continue to work or may need to be re-authorized - check with a test User after rotating.

Every tool call made through an MCP Plugin is recorded by Planhat: which User triggered it, which tools were called, and when. This lets you answer "who retrieved what, and when" without asking the external application - which matters most for Central connections, where the external application only sees one shared account.

Click the image to view it enlarged

These are the points your security or IT team are most likely to ask about.