Yes, but not the way most people expect. As of 8 September 2026, a Breeze agent connects to MCP servers vetted by HubSpot — eight of them today — and the documentation describes no field where you paste the URL of a server of your own. One door is still open for knowledge that belongs to you: the Zapier connector, the only one on the list configured with a server URL you supply yourself.
This guide starts from what the documentation says today rather than what we would like it to say. Then it walks the two workable routes, and what each one costs.
The dated record — what HubSpot allows as of 8 September 2026
The device in this article is a record: dated, sourced facts, to be re-checked before you rely on them. HubSpot moves fast here, and half the articles floating around describe a product from six months ago.
- The mechanism is called HubSpot MCP Client. It is what lets a Breeze agent call an external MCP server while it runs.
- The list is closed: Notion, Atlassian, Asana, Zapier, G2, Linear, Gong, Amplitude. Eight names, all established platforms.
- The install path: Agents > Agent Hub, Agents tab, hover the agent, Clone; then, in the Actions section, Add action, the Connectors tab, hover the server you want and hit Connect and add, then authorise on the provider's side.
- Zapier is the exception: instead of an OAuth flow, you paste the Server URL copied from Zapier's Connect tab and confirm with Connect to Zapier MCP.
- Prerequisites: Agent Builder permissions, a Starter tier or above on one of the Hubs, and the HubSpot Credits some agents consume.
One more line of the record, the one most often missing: nothing on that list is a way to let Breeze read your repository. These are connectors to SaaS tools, not to your product.
The arrow points two ways, and the two get confused
Two objects carry the letters MCP at HubSpot, and they run in opposite directions.
mcp.hubspot.com: HubSpot exposes its CRM. Your MCP client — Claude, Cursor, ChatGPT — queries your contacts, deals and tickets. The arrow runs from HubSpot to your agent.- HubSpot MCP Client: here Breeze is the client, calling an external server. The arrow runs from a third-party tool into Breeze.
Grounding a Breeze agent in your product is the second arrow. Whenever a page promises to "connect HubSpot to MCP", check which way it points first: nine times out of ten it means the first one, which does not solve the problem posed here. If the vocabulary is still fuzzy, our plain-language definition of an MCP server runs three paragraphs.
"What changed in the product this week?"
That is the question that settles it. A Breeze agent talking to your customers or your sales team gets it in twenty shapes: is the behaviour in this ticket still current, does the update break the customer's integration, does that field still exist.
An agent fed from a knowledge base answers from pages written on a date. They started ageing at the next deployment, and nobody raised a hand about it. We described that mechanism in why a support bot gives stale answers after a release, and its agent-side version in release awareness.
An agent wired to a source derived from real code answers differently. An illustrative example of the gap:
- Without: "Our documentation states that exports are produced in CSV."
- With: "The CSV export has included a header row since the 3 September deployment. The
client_reffield was renamedcustomer_ref; the old name is still accepted."
The second answer does not come from a page someone wrote. It comes from the diffs.
Route 1 — the Zapier bridge
This is the only documented route today for bringing a source that is not on the list of eight into Breeze.
How it works: Zapier's MCP server exposes Zapier actions as MCP tools, and Webhooks by Zapier can fire an arbitrary HTTP request — GET, POST as JSON, headers included. So you build a Zapier action that calls your answers endpoint, scope the Zapier MCP server to that single action, and paste its Server URL into Breeze.
What it costs, without dressing it up:
- One more intermediary. Zapier sees the question and the answer go past. For a team under a strict customer contract, that hop is worth settling before you wire it.
- Descriptions you have to write well. Breeze decides to call a tool from its name and description. "Answers questions about current product behaviour and about what changed since a given version" gets called at the right moment; "product tool" never does.
- A Zapier plan, plus the HubSpot Credits your agent runs consume.
What it buys: a Breeze agent that, for the first time, answers about your product as it stands this morning.
Route 2 — stand the server up, and let the list open
Eight connectors in April 2026, and the ecosystem has no reason to stop there. The long route is to have, on the day the list widens, an MCP server already running and already queried by other agents.
That is the position we hold: one MCP server per project, connected read-only to the GitHub repository, its answers derived from the real code and the git history, re-synced on every push. It is already reachable by the MCP clients that accept a free-form URL — Claude, Cursor, and Intercom Fin, whose custom MCP connector takes any URL. The DeployIt server is in early access, under a design partner program: see how it works.
Meanwhile the other surface stays open on the human side: a help center and a Messenger fed from the same source, without going through Breeze.
"I'll build the Zap myself against the GitHub API"
The objection is fair, and for a well-equipped team it covers part of the ground. A webhook hitting the GitHub API will return the latest commits, their authors, their messages.
Two walls come next. The first: a commit message that says "fix" tells an agent nothing, and your customers never phrase their questions in your commit vocabulary. Answering "why did this behaviour change" means reading the content of the change, not its label. The second: that Zap carries a GitHub token, hosted at a third party, with whatever scope you granted it. An answers endpoint reverses the relationship — Breeze receives an answer, never a key to your repository.
"But that expert reads my repository"
It does, and here are the terms. The GitHub connection is read-only. Each project gets its own server: the expert for one product knows nothing but that product. Answers are derived from commits and diffs, never a dump of source code back to whoever asked. Access is revocable at any time, and the code never leaves your repository.
That is also what separates this approach from its neighbours: Context7 and DeepWiki cover libraries and public repositories, Mintlify generates an MCP server from written documentation. The subject here is your private product, derived from the code itself, fresh on every deployment.
Mini-FAQ
Does Breeze accept an arbitrary MCP server URL? Not as of 8 September 2026. The docs describe a list of eight connectors; only Zapier is configured with a URL you provide.
Do I need a particular HubSpot plan? Yes: Agent Builder permissions and at least a Starter subscription on one of the Hubs. Some agents consume HubSpot Credits on every run.
What if my agents live elsewhere — Fin, Claude, Cursor? Those accept an MCP server URL directly. The Fin guide is here; the setup is shorter than the Zapier route.
Will this record still be accurate in three months? Probably not on the connector count. Re-check the list in HubSpot's knowledge base before wiring anything — that is what the date at the top of this article is for.
What to take away
Breeze is not open to private MCP servers yet. The Zapier route works today and goes up in an afternoon; the long route is having a product expert already in place when HubSpot widens its list. Either way the piece to prepare is the same: a source of truth derived from the code, rather than one more page to keep current.
The DeployIt MCP server is in early access. The design partner program is open to teams that want to wire it into their agents now.