It's no secret that in today's day and age, AI tooling is everywhere, and AI applications are fighting over themselves to have the best, most robust set of connectors so that you can combine LLMs with data or capabilities from individual services that we use day to day.

Think of Plugins and Connectors in tech like ChatGPT and Claude. These handy features let them take actions, such as have Claude summarize your email, create an AI-generated Google Doc, or have Codex scan through your marketing data to analyze latest trends.

However, it's not all smooth sailing in todays landscape.


The Problems

  • Multiple harnesses/clients: If you wanted to use a connector with Claude code, ChatGPT, and Cursor, you'd need to set up that same connection inside of each client individually.
  • Not every tool exists with native connections: Even for major companies like Google, not all of their features are exposed as native connections. Eg, Google Slides is not in Claude. As well, for most smaller companies, they don't have native connections set up for AI clients
  • Sometimes requires a technical eye: while a lot of the time a technical person can connect to virtually anything if they are willing to use third-party services or write their own code, this requires developer expertise
  • No guardrails: unless you set up these guardrails yourselves for each client and connector, there's nothing stopping things such as prompt injection, or scrubbing PII/PHI.


The Solution

After a few hours hunched in a room with Mark Johnson (Staff Engineer), the answer become obvious,

an MCP of MCPs (kindof)

Firstly, you might be asking yourself, "What on earth is an MCP, and why would it be necessary or helpful to build one that's a collection of other MCPs?"

Think of an MCP like an API, but just built in a way so that AI can easily use it. For instance, an MCP always has a standard endpoint to list tools, and tools always have well-defined parameters, so with a bit of digging an agent can see exactly what capabilities it has access to.

All those connectors I mentioned earlier are actually using MCP under the hood. This is a powerful and useful fact, because this means that if we write our own MCP that can connect to other MCPs, we can manage everything in one handy spot and open up a whole world of possibilities.

We decided to call this tool EKG, for Enterprise Knowledge Gateway.


The Why

Managing everything in single MCP means a whole lot of benefits:

  • We can create our own UI, and manage the catalog of connections ourselves
  • Non-technical users can simply click a few buttons, and use browser Oauth or API keys to connect to all their services without having to write code or JSON configs
  • We can write our own code for services we use that don't have native MCP connectors, like Google Slides, Iterable, GCAI etc
  • We don't need to write the connection for each application individually, so users can freely connect the EKG application to Claude, ChatGPT, or any other client, and not have to continuously add each service connector individually
  • We can make this a singular spot for adding input and output validations, things like prompt injection, dangerous widespread operations, or PHI/PII and company secret protections, all written in one single spot

Earlier I wrote that EKG is "kindof" an MCP of MCPs. While MCPs are the main idea for the application, not every service has an MCP (if they just have an API), so we use some of the native Anthropic libraries to wrap those APIs in a way that they're used as an MCP server. To the user, it looks all the same, but under the hood, it's actually quite different.


The How

Building EKG had a lot of twists and turns and involved many different people.

Firstly, the original idea for EKG was simply that it would be able to get information from various sources and consolidate it into one. However, that idea morphed into something more practical, including the ability to take actions in different services, such as creating or updating content.

This also went through a pretty exhaustive and ongoing set of reviews. We originally released this as a limited beta to keep the risk radius small, and to give us time to work on issues the Security team had flagged. We also went through compliance and security reviews for all the various connectors that we wanted to add to EKG.

At the end of the day, this left us with an application that we were happy and confident with, and I couldn't have been prouder to be a part of building it.