On this page
Put Coworker to work on your stack.
Connect Salesforce, Slack, Jira and run your first agent in minutes.
Enterprise AI
HubSpot MCP: What It Does, and What It Doesn't Cover
HubSpot's own MCP server connects AI tools to HubSpot data. Here's what it covers, what it doesn't, and when a unified layer is the better fit.
What HubSpot's MCP server actually is
HubSpot publishes its own MCP server directly, split into two pieces: a remote MCP server for general AI tool access to HubSpot data, and a local Developer MCP server aimed at agentic development tools working against HubSpot's CLI and Developer Platform. Both are free to use and maintained by HubSpot itself, which clears the "who maintains this" question that matters for any MCP server, official or community-built, well before a security review ever asks it.
That official backing is worth noting given how the broader MCP ecosystem looks: plenty of connectors for popular platforms are unofficial community projects with uneven maintenance. HubSpot's is not one of those. It's a first-party tool, actively documented, sitting alongside the same official-server pattern GitHub and Salesforce have also shipped for their own platforms in 2026.
What it covers well
For anything scoped specifically to HubSpot: pulling contact records, checking deal stages, querying marketing data, or letting a coding assistant reference HubSpot's own API documentation while building an integration, the official server is the natural first choice. It's purpose-built for exactly that surface area, and being HubSpot's own product, it stays current with HubSpot's own API changes without waiting on a third-party maintainer to catch up.
Developer teams building custom HubSpot integrations get a real benefit from the local Developer MCP server specifically: an AI coding tool that can reference the actual current state of the HubSpot Developer Platform while writing code against it, rather than working from training data that may already be stale. A rundown of real use cases covers what teams are actually doing with it today, from CRM data lookups to automating parts of the sales workflow.
Where it stops
The HubSpot MCP server knows HubSpot. It has no visibility into Slack, no visibility into a support ticket in a different system, no visibility into a GitHub issue referencing the same customer. A question like "what did this account complain about in Slack, and does our HubSpot record reflect it" isn't answerable through the HubSpot server alone, because the two halves of that question live in two systems it has no connection to.
This is the same pattern as every single-vendor MCP server: excellent for questions scoped entirely inside that vendor's product, structurally unable to answer anything that spans systems. One detailed breakdown of the server's scope puts it the same way: the value is real, but it's bounded to what HubSpot itself knows.
Single-vendor server vs. a unified layer
| HubSpot's own MCP server | A unified MCP layer | |
|---|---|---|
| Data it can see | HubSpot only | 50+ connected apps at once |
| Maintained by | HubSpot | Depends on the vendor |
| Cost | Free | Varies by vendor |
| Best for | HubSpot-scoped questions and dev work | Questions spanning multiple systems |
| Cross-system context | Not possible | Native |
Coworker
Put Coworker to work on your actual stack
Connect Salesforce, Slack, Jira and run your first agent in minutes.
What to check before connecting it
Even a first-party, officially maintained server like HubSpot's is worth reviewing before rollout, not because it's untrustworthy, but because the questions worth asking are the same for any MCP server: what scope of access does the connection request, who on the team can install it, and does the client application (Claude Code, Cursor, or whichever tool is connecting) get read-only access or write access to CRM records.
Write access matters more here than it might for a documentation lookup. A misconfigured agent with write access to HubSpot could update deal stages, overwrite contact fields, or send communications on a workflow's behalf. None of that is a flaw in HubSpot's server specifically; it's the same governance question MCP security covers for any server with access to systems customers can see the effects of.
Setting expectations for a team rollout
For a single developer connecting HubSpot's MCP server to their own coding tool, the setup is genuinely simple: authenticate, connect, and start working against HubSpot's documented API surface with an assistant that has current context. The complexity shows up once more than one person on a team wants the same thing. Each developer needs their own connection and their own credentials, there's no single place to see who on the team has HubSpot MCP access at any given time, and revoking access when someone changes roles means finding every individual connection rather than flipping one switch.
That's not a criticism of HubSpot's implementation specifically. It's the standard shape of single-vendor, individually-installed MCP servers, and it's exactly the gap a centrally-managed layer is built to close once a rollout grows past one or two people.
The practical marker for when this starts to matter is usually the first access review. A security or IT team asking "who can our AI tools reach inside HubSpot, and how do we know" is the moment a scattered set of individual connections stops being a convenience and starts being a question nobody has a fast answer to. Teams that hit this point before rolling out MCP more broadly tend to have an easier time than teams that hit it after.
Where Coworker MCP fits
Coworker MCP doesn't replace HubSpot's own server for HubSpot-specific developer work; it solves the adjacent problem HubSpot's server was never built for. One connection gives Claude Code, Cursor, ChatGPT, Windsurf, or any MCP-compatible client access to 50+ connected apps including HubSpot, Slack, Jira, Salesforce, GitHub, and Google Drive, searchable and reasoned over as one system. The question that HubSpot's server can't answer on its own, spanning HubSpot plus whatever else the full picture requires, is exactly the case Coworker MCP is built for.
See how to choose the right MCP setup for your team, or read about MCP security before connecting anything with write access to customer records.
See how Coworker MCP works, or book a demo to see it connected to HubSpot alongside the rest of your stack.
Frequently asked questions
Does HubSpot have an official MCP server?
Yes. HubSpot publishes its own MCP server directly, free, covering both general AI tool access to HubSpot data and a local Developer MCP server for building against HubSpot's Developer Platform.
Is HubSpot's MCP server free?
Yes, HubSpot's MCP server is free to use.
Can HubSpot's MCP server access other tools like Slack or Salesforce?
No. It's scoped entirely to HubSpot's own platform and data. Answering a question that spans HubSpot and another system requires either a separate connection to that system or a unified layer that covers both.
Should I use HubSpot's MCP server or a unified MCP layer?
Both, for different jobs. HubSpot's own server is the better choice for HubSpot-specific development work. A unified layer like Coworker MCP is the better choice when the task spans HubSpot and other systems your team uses.
What other platforms have shipped their own official MCP servers?
GitHub and Salesforce have both shipped official, first-party MCP servers in 2026, following the same single-vendor, single-platform pattern HubSpot's own server follows.
Related reading
Ready to get started?
Put Coworker to work inside your actual stack
Connect Salesforce, Slack, Jira, whatever you use, and run your first agent in minutes.