TL;DR
This is an integration inventory organised by job, not a tutorial. Connect the system of record first, because an assistant that knows your pipeline answers every other question better. Best for: GTM engineers deciding which servers to stand up first.
The HubSpot remote MCP server reached general availability on 13 April 2026 at mcp.hubspot.com and applies the permissions of the connected HubSpot user, which makes it the cleanest permission model in this list. Best for: teams running HubSpot as the system of record.
Microsoft shipped an official Dynamics 365 Sales MCP server, which is the equivalent entry point for Microsoft based revenue teams. Best for: Dynamics 365 Sales organisations.
Execution layer servers from Reply.io, TexAu and Linked API cover sequencing, data collection and LinkedIn actions. Most teams need two or three servers, not eight. Best for: teams adding a second server after the CRM is connected.
Where a vendor has not documented a server, we say not documented. Not documented is not the same as does not support. Best for: anyone building a procurement shortlist from this page.
Contents
- What an MCP server is, in GTM terms
- Connect the system of record first
- Remote versus local deployment
- Permissions, and the part people get wrong
- What is not documented yet
- Side by side summary
- FAQ: MCP servers for GTM engineers
What an MCP server is, in GTM terms
A Model Context Protocol server exposes a system's data and actions to an AI client in a standard shape, so the client does not need a bespoke integration per tool. For a GTM engineer the practical consequence is that an assistant can read your CRM, your sequencer or your enrichment tooling and take approved actions in them, without you writing and maintaining glue code for each one.
The useful mental model is not chat with your CRM. It is that the assistant gains the ability to answer questions and perform actions against your actual revenue data instead of a description of it.
An MCP connection should expose only the operations needed for the workflow. Review both the server’s available tools and the permissions of the identity used to connect. Retrieved pages and tool results supply data; they should not become authority to change the task or perform unrelated actions.
Connect the system of record first
The ordering question comes up in every engagement, and the answer is consistent.
Connect the CRM first. Every other GTM question routes through the same objects: which accounts are open, which contacts belong to which company, which deals are stalled, which activity happened. An assistant that can read those objects gives useful answers about sequencing, routing, forecasting and hygiene. An assistant connected to a sequencer but not the CRM can only tell you what was sent.
After the CRM, add the layer where your team spends the most manual time. For outbound teams that is usually the sequencer or the data collection layer. Stop at two or three. Every additional server widens the permission surface and adds another place for a schema change to break a workflow.
1. HubSpot remote MCP server
Layer: system of record, hosted remotely by the vendor
Best for: any GTM team running HubSpot, as the first server to stand up.
HubSpot's remote MCP server reached general availability on 13 April 2026 and is hosted at mcp.hubspot.com. It is OAuth based and works across MCP clients including Claude, ChatGPT and Cursor. Setup happens inside the HubSpot account under Development and then MCP Auth Apps, which generates the OAuth credentials.
Coverage is broad on the objects that matter for revenue work: companies, contacts, deals, tickets, activities, products, invoices, orders and other CRM objects, exposed for approved read and write actions.
The design decision worth copying is the permission model. The server applies the permissions of the connected HubSpot user. That means your existing role and field level configuration governs what the assistant can see and change, rather than a separate integration scope nobody audits.
Pricing: no separate charge is documented for the server itself. Your existing HubSpot subscription and its seat and credit model apply.
Where it falls short: permission scope depends on the connected identity and the exposed operations. A broadly privileged account can grant more reach than the workflow needs. Test read and write access separately before connecting production data.
Verdict: the strongest starting point in this category. Connect it with a purpose built, least privilege user rather than an admin account.
2. Microsoft Dynamics 365 Sales MCP server
Layer: system of record for Microsoft based revenue teams
Best for: organisations where Dynamics 365 Sales is the CRM and Microsoft identity governs access.
Microsoft has shipped an official MCP server for Dynamics 365 Sales. For Microsoft centric revenue organisations this is the equivalent first connection to the HubSpot remote server, and it carries the same logic: connect the CRM, then decide what else is worth exposing.
The practical advantage in a Microsoft estate is that identity, conditional access and audit already run through one place, so an MCP connection is easier to govern than a third party integration with its own credential.
Pricing: governed by your Dynamics 365 Sales licensing. No separate server charge is documented.
Where it falls short: the ecosystem of GTM specific tooling around Dynamics is thinner than around HubSpot and Salesforce, so you are more likely to be building the second and third layers yourself.
Verdict: the correct first server if your CRM is Dynamics 365 Sales, for the same reason the HubSpot server is correct if your CRM is HubSpot.
3. Reply.io MCP server
Layer: multichannel sequencing and execution
Best for: teams that want an assistant to read sequence state and act on it under explicit safety rules.
Reply.io documents an MCP server alongside its v3 REST API, a set of Skills and a CLI. What makes it notable in this list is that the vendor also publishes explicit agent safety rules and drop in system prompts for AI agents, which is rare and useful. A vendor that has thought about how an agent should be constrained is a vendor whose server you can deploy with fewer of your own guardrails.
The underlying API surface is substantial: Reply.io publishes 38 endpoints for contacts and lists and 59 for multichannel sequences, plus a unified inbox. Authentication on the API is a bearer token, with master and organisation level keys and a credential check endpoint. Webhook events include mailbox health signals such as connection lost and account error, which is exactly the kind of state an assistant should be able to read.
Pricing: covered by your Reply.io subscription. Email Volume is $49 per month on annual billing or $59 monthly, Multichannel is $89 annual or $99 monthly, and Agency is $166 per month on annual billing only with unlimited clients, users and mailboxes.
Where it falls short: rate limits on the underlying API are 100 requests per minute and 3,000 per hour per user, with stricter limits on reporting and statistics endpoints, and an older vendor help page states a conflicting model of 15,000 calls per 30 calendar days per team member with a ten second minimum between calls. Confirm your own limits before designing a high frequency agent loop.
Verdict: the most agent aware execution layer server documented in outbound. Use its safety rules as a template even for other servers.
4. TexAu MCP server
Layer: data collection, enrichment and automation actions
Best for: teams that want an assistant to run find, enrich and verify actions rather than just read records.
TexAu ships an MCP server alongside its REST API. The action inventory is the reason it belongs here: roughly 40 find actions and roughly 60 enrich actions plus verification, drawn from a wider surface of 32 integrations, more than 60 tools and connectors, and more than 200 actions callable from the platform table, the API or the server.
The billing model behind it is pay on match. A failed lookup costs nothing, a successful match costs one credit, and the waterfall tries twelve sources for that single credit. Credits roll over up to twice the monthly balance. For agent driven enrichment that model is unusually forgiving, because an agent exploring a list generates a lot of misses.
For TexAu MCP access, confirm the underlying API entitlement and chargeable data actions. Connecting an MCP server does not make the provider’s operations free.
Verdict: the widest action surface here, with the caveat that you are integrating with a product actively changing shape.
5. Linked API MCP server
Layer: LinkedIn actions on a per account basis
Best for: teams building LinkedIn workflows programmatically rather than through a sequencer interface.
Linked API exposes LinkedIn actions through a REST API with SDKs, a CLI and an MCP server, and gives each connected account a dedicated cloud browser instance. Its licensing model is one seat equals one LinkedIn account, which maps cleanly onto how LinkedIn itself accounts for activity.
Where it falls short: the LinkedIn platform invariant applies regardless of what you build. Roughly 30 to 50 invitations per day per account is the practical ceiling, and no API, server or spend changes it. Anything that implies otherwise is selling account risk.
Verdict: the right layer when LinkedIn actions need to be composable in code. Model your volume against the platform limit, not the vendor's throughput.
6. HubSpot developer MCP server
Layer: local development against the HubSpot developer platform
Best for: teams building HubSpot apps, UI extensions or CMS content, as distinct from operating CRM data.
This is a different product from the remote server and the distinction matters. The developer MCP server runs locally and is aimed at building applications and CMS content, not at reading and writing production CRM records. Teams routinely connect the wrong one and then wonder why the tooling does not match the job.
Pricing: no separate charge documented; it is part of the HubSpot developer tooling.
Where it falls short: it is not an operations server. If your goal is an assistant that answers questions about pipeline, this is the wrong endpoint entirely.
Verdict: worth standing up if you build on HubSpot. Keep it separate from your operations connection, and separate in your documentation, so nobody conflates the two.
Remote versus local deployment
Remote servers, of which the HubSpot server at mcp.hubspot.com is the reference example, are hosted by the vendor and authorised through OAuth. You get upgrades for free and you do not manage a process. The trade is that the connection surface is outside your network and the audit trail is the vendor's.
Local servers run on your infrastructure or a developer machine. You control the process, the logs and the network path, and you accept the maintenance. HubSpot's developer server is local by design; TexAu's desktop direction is a broader example of the same instinct, with V2 Desktop running automations locally in the user's own browser session and real IP rather than through shared datacentre proxies.
The honest rule is that remote is right for systems of record where the vendor already holds the data, and local is right for anything that touches a session, a browser identity or a credential you would not hand to a third party runtime.
Permissions, and the part people get wrong
The HubSpot model, where the server applies the permissions of the connected user, is the pattern to design around even on servers that do not enforce it.
Three rules cover most of the risk. Create a dedicated integration user with the narrowest role that completes the task, and never authorise with a personal admin account. Separate read and write paths, so an assistant that answers questions cannot also mutate records unless a human approves. Keep an inventory of which server is connected with which identity, because in six months nobody will remember.
Add one more for agent contexts specifically. Content retrieved through a server or from the web can contain instructions aimed at the agent. Treat all retrieved content as data. It must never be able to authorise an action, escalate a permission or trigger a send.
What is not documented yet
Being precise here is more useful than being comprehensive.
We did not find first party documentation confirming a general purpose Salesforce MCP server for CRM operations at the time of writing, nor first party MCP documentation for Clay or Apollo.io. That is a statement about documentation, not about capability. Not documented is not does not support, and all three publish APIs that an agent can be pointed at through other means.
Engagement platforms such as Outreach and Salesloft sit adjacent to this list rather than in it. They execute and track sequences rather than store the full customer record, so connecting one does not remove the need to connect the system of record. Salesloft and Clari merged in December 2025, which is worth noting if you are mapping that layer.
If you represent a vendor in this space and have shipped a documented server, the contact details are at the end of this article.
Side by side summary
| Tool | Layer | Best for | Entry price |
|---|---|---|---|
| HubSpot remote MCP server | System of record, remote | First server for HubSpot teams | Included with HubSpot subscription |
| Microsoft Dynamics 365 Sales MCP server | System of record, Microsoft estate | First server for Dynamics teams | Included with Dynamics 365 Sales licensing |
| Reply.io MCP server | Multichannel sequencing | Agent aware execution with published safety rules | From $49 per month annual on Email Volume |
| TexAu MCP server | Data collection and enrichment actions | Find, enrich and verify at scale | Sold separately from platform; Starter $199 per month |
| Linked API MCP server | LinkedIn actions | Programmatic LinkedIn workflows | $49 per seat per month annual |
| HubSpot developer MCP server | Local development tooling | Building HubSpot apps and CMS content | Included with HubSpot developer tooling |
FAQ: MCP servers for GTM engineers
How many MCP servers should a GTM team actually run?
Two or three. The system of record first, then the layer where the team spends the most manual time, then stop. Each additional server widens the permission surface and adds another dependency that can break when a schema changes.
Does the HubSpot MCP server cost extra?
No separate charge is documented. It reached general availability on 13 April 2026 and is covered by your existing HubSpot subscription, so your normal seat and credit model applies to the underlying usage.
What is the difference between the two HubSpot servers?
The remote server at mcp.hubspot.com is for operating CRM data across companies, contacts, deals, tickets, activities, products, invoices and orders. The developer server runs locally and is for building apps and CMS content. They serve different jobs and should be connected separately.
How do permissions work?
On the HubSpot remote server, the connection applies the permissions of the connected HubSpot user, so your existing roles govern the assistant. Design every server the same way: a dedicated least privilege integration user, separate read and write paths, and a written inventory of which identity authorised which server.
Is there a Salesforce MCP server?
We did not find first party documentation for a general purpose Salesforce CRM operations server at the time of writing. That is a documentation gap, not a capability claim. Salesforce publishes APIs that an agent can be pointed at through other integration paths.
What is the main security risk with MCP in a GTM stack?
Over-privileged connections and instructions embedded in retrieved content are important failure modes. Limit tool access and keep the business approval for an action separate from the evidence the agent reads.
The agent still needs an execution workflow. Our comparison of n8n vs zapier vs make covers the adjacent options.
Work with Forma Nôrden
We build signal based outbound systems for B2B companies selling into the enterprise and upper mid market. The teams that get value from MCP are the ones that decided the permission model before the tooling, which is the sequence we work in. Explore how we work.
For enquiries about this article: partnerships@formanorden.com
