HubSpot and Salesforce MCP for sales teams: let an agent update your CRM, with approvals

What sales teams actually want an agent to do

The first two should happen at once. The last two are what a sales manager wants to see before they happen. That split is the design below.

The connectors

Contact listing answers to one shared name, crm.contact.list, across 34 connectors, so the same agent instructions work on whichever CRM is connected. See canonical action names.

HubSpot and Salesforce each offer MCP access of their own. HubSpot's remote MCP server, at https://mcp.hubspot.com, has been generally available since 13 April 2026: each user signs in with OAuth 2.1 and PKCE, and every action respects that user's HubSpot permissions (HubSpot developer changelog, checked 22 October 2026). If you need one CRM in one client with the vendor's permissions, that may be enough. A gateway adds per-agent keys, caps, approval rules, one ledger, and questions that join the CRM with billing or support.

Step 1: Connect the CRM once

Both CRMs use OAuth. Create an app in the CRM (a HubSpot app with OAuth, or a Salesforce connected app), authorise it once as an admin, and store the resulting tokens with the app's client id and secret. actionlake renews the access token from the refresh token as it expires.

{
  "op": "connections.create",
  "service": "salesforce_sobjects",
  "name": "default",
  "secrets": { "access_token": "…", "refresh_token": "…", "client_id": "…", "client_secret": "…" },
  "setup_data": { "instance_host": "https://yourcompany.my.salesforce.com" }
}

For HubSpot the shape is the same, with "service": "hubspot_crm" (and again for hubspot_deals) and no setup_data. Ask connections.requirements first; it returns the exact fields each service needs, free. Tokens are sealed on arrival and never returned.

The app's OAuth scopes are the outer limit. Grant the CRM app only the objects your agents need; actionlake's keys narrow it further, never wider.

Step 2: A key per rep, with deal changes gated

Mint keys in the console or with your root key over REST. Keys are never minted through an OAuth connection.

{
  "name": "rep-agent-jordan",
  "holder": "agent",
  "allowed_actions": [
    "hubspot_crm.read:*", "hubspot_deals.read:*",
    "hubspot_crm.notes.create", "hubspot_crm.contacts.update",
    "hubspot_deals.deals.update"
  ],
  "cap_calls": 2000,
  "confirm_policy": "human",
  "approver": "[email protected]",
  "approval_rules": [
    { "match": "hubspot_deals.deals.update", "approver": "[email protected]" }
  ]
}

What this key does:

• Reads anything in HubSpot CRM and Deals, at once.
• Notes and contact fixes go straight in. They are writes, so they are recorded, but nobody waits.
• Deal updates wait. The sales manager gets an email with a signed link, or decides in the console. The update runs when they approve; a decline stops it.
• Archiving is not in allowed_actions, so it is refused. If you add it, it is a destructive action: under confirm_policy: human it needs a person's approval, and the agent cannot confirm it itself.

For Salesforce, the same pattern uses salesforce_sobjects.read:*, salesforce_sobjects.tasks.create and a rule on salesforce_sobjects.opportunities.update.

Step 3: What the rep's agent sends

The rep says: "Move the Acme deal to Contract sent, 48,000." The agent first reads the pipeline's stages, because HubSpot wants the internal stage id, not its label. Then:

{
  "action": "hubspot_deals.deals.update",
  "input": { "record_id": "18734420115", "stage": "contractsent", "amount": "48000" },
  "intent": "Jordan asked to move the Acme deal to Contract sent at 48,000 after today's call."
}

The call is parked, not refused. The reply names the approval it is waiting on. When the manager approves, the update runs and the run records who approved it. The intent sentence is what the manager reads in the approval mail, so the agent's reason travels with the request.

Before anything runs: check

For bulk or unfamiliar changes, the agent sends the same payload to check first. It validates the input against HubSpot's or Salesforce's schema as the connector describes it, confirms the key may run it, and says it will need an approval and roughly what it will cost. It is free and sends nothing. See dry run.

Questions across the CRM and other systems

A sales question often needs another system. With ask, the agent fetches from both and joins on the company, and only the answer returns:

• "Which customers in our pipeline are overdue on invoices?" HubSpot companies with Xero or QuickBooks Online.
• "Which accounts up for renewal have open support tickets?" Salesforce accounts with your help desk.

See cross-system questions for how the join matches companies.

A rollout that keeps the forecast clean

Each step is a keys.update on the rep's key. Nothing about the CRM connection changes, and no rep loses access while you adjust.

What it costs

Each request sent to HubSpot or Salesforce that returns an answer is one upstream call. Searches for actions, schema reads, check, cache hits and failures you did not cause (a 401, 403, 429, 5xx or a timeout) are free. A request the CRM rejects as invalid, such as a 400 or 404, is billed. Free includes 100,000 calls a month; Starter is US$49 a month for 250,000. A rep's agent doing call prep and logging typically makes a handful of calls per request. See pricing.