MCP: how we connect AI to the tools your team already runs

Most AI integrations are built the same way: one team writes a custom connection between their AI tool and their CRM, and another team builds a completely different custom connection between a different AI tool and that same CRM, and neither one works with the other's setup. It's fragmented, slow to build, and expensive to maintain. MCP — the Model Context Protocol — was designed to solve that, and it's changed how we build AI integrations for clients.

What MCP actually is

MCP is an open protocol that Anthropic released in late 2024. It defines a standard way for AI models to communicate with external tools and data sources. Instead of every integration being a custom one-off, MCP creates a common language: any MCP-compatible AI can talk to any MCP-compatible server, and the connection works regardless of which AI you're using or which tool you're connecting to.

There are three pieces. The host is the AI application — Claude.ai, Claude Desktop, or any AI tool that's been built to support MCP. The client is built into the host and handles the back-and-forth communication. The server is a small service that sits in front of your tool — HubSpot, Slack, your database, whatever — and translates the AI's requests into API calls that the tool understands. When the AI needs to look something up or take an action, it talks to the server; the server talks to the tool; the result comes back to the AI.

Existing MCP servers we use for clients

The MCP ecosystem has grown quickly. For most common B2B tools, a server already exists — either published officially by the vendor or built and maintained by the open-source community. The ones we reach for most often:

• HubSpot — read and write contacts, companies, deals, and activity history. Partners can ask "what's the last touchpoint on the Garrison account?" and get a real answer from live CRM data.
• Slack — search conversations, read channel history, send messages. Useful for automations that need to surface information from Slack or post updates back to it.
• GitHub — read repositories, open and update issues, review pull requests. For software clients, this means the AI can reference actual code and project state instead of a summary someone wrote.
• Google Drive and Docs — read, search, and in some cases write documents and spreadsheets stored in Drive.
• Notion — read and write pages and database records, useful for teams running their ops wiki or project tracker in Notion.
• Postgres and other databases — run structured queries directly against a database, which is often the cleanest way to give an AI access to operational data without building a full API layer first.
• Jira — read issue status, update fields, create tickets. We use this for professional services clients who track client work in Jira and want the AI to surface status without someone manually pulling reports.

When we build a custom MCP server

We check for an existing server first. If one exists and covers what the client needs, we configure it and move on. But a few situations consistently push us toward building a custom server instead.

The most common: a client has a proprietary internal tool that no community server covers. We've built custom MCP servers for homegrown project management systems, industry-specific CRMs, and internal databases with schemas that wouldn't map cleanly to a generic SQL server. The MCP server we build is thin — it exposes exactly the operations the AI needs and nothing more. A partner at a professional services firm wanted to ask Claude "what's the status on the Harrington engagement?" and get a real answer from their internal system. We built an MCP server that read from their project database, surfaced the right fields, and handled the firm's specific naming conventions. The partner now uses it every day.

The second situation: an existing server exists but doesn't expose the right subset of data. Some open-source MCP servers are intentionally broad; they expose everything the underlying API offers. For a client with sensitive data, that's more access than we want to scope to an AI. A custom server lets us define exactly which records the AI can reach and what it can do with them.

Third: the client needs to combine data from multiple sources into one coherent response. A single AI query might need to pull a contact record from HubSpot, check their recent email thread in Gmail, and look up their contract status in a spreadsheet — and surface all of that as one answer. A custom MCP server can orchestrate those calls and return a unified result, rather than asking the AI to stitch together three separate responses.

How we decide: existing versus custom

We start every MCP conversation with two questions: what does the AI need to read or do, and does an existing server cover exactly that? If the answer is yes, we configure the existing server and test it. If the answer is "mostly, but not quite," we look at whether the gap is small enough to work around or significant enough to warrant a custom build. If no server exists for the tool at all, we build one. The decision is always about what actually gets used in production — a perfectly designed integration that doesn't fit the client's real workflow isn't done, it's just deferred maintenance.

Frequently asked questions

Does our team need to be technical to use an MCP server?

Not to use one once it's set up. MCP servers are configured once by us during the build. After that, the AI handles the communication automatically — your team just asks questions or triggers workflows the normal way, and the MCP layer runs in the background.

Is MCP the same as a connector or a Skill?

Not exactly. Connectors (like claude.ai integrations or ChatGPT's connected apps) are user-level authorizations that let the AI read from specific sources during a conversation. MCP is the developer-level protocol underneath that — it defines how AI models and external tools communicate. A connector might use MCP under the hood, or it might not. A Skill defines how the AI behaves; MCP defines what it can reach.

Can we use an existing MCP server and a custom one at the same time?

Yes. Most client setups use a mix — existing servers for standard tools like HubSpot or Slack, and a custom server for whatever proprietary or niche system the existing ecosystem doesn't cover. The AI sees them all as tools it can reach and uses whichever is relevant to the request.